Merb 1.0, JRuby docelową platformą?

Opublikowane przez Jarosław Zabiełło Mon, 10 Nov 2008 01:13:00 GMT

Ezra Zygmuntowicz oficjalnie w swoim blogu obwieścił wydanie wersji 1.0 dla frameworka Merb. Mimo, że formalnie Merb nie ma zamiaru walczyć z Rails, na pewno taka konfrontacja nastąpi. Tym bardziej ciekawa, że wkrótce ma wyjść Rails 2.2, który wprowadził trochę znaczących zmian w stosunku do wersji poprzednich, m.in. wielowątkowość oraz wsparcie dla wersji międzynarodowych.

Rails to aktualnie rozpędzona lokomotywa, jest starszy i bardziej znany od Merba, wydaje się do niego całkiem sporo książek (w tym też w jęz. polskim). (Ze swojej strony, trochę się do tego też dokładam dzięki mającej być lada tydzień wydanej “Ruby on Rails 2.1. Tworzenie nowoczesnych aplikacji internetowych”, o której napiszę niedługo więcej)

Generalnie można powiedzieć, że na pewno Rails ma więcej książek i dokumentacji oraz pluginów. Zaś mająca wyjść wersja Rails 2.2 dodaje też wsparcie do tworzenia stron w wielu językach narodowych (do Merba dopiero to jest tworzone).

Do Merba nie ma na razie aż tyle materiałów. Ale poza agregatorem blogów, Wiki i dokumentacją do API powstaje ważna książka Merb in Action (tworzona zespołowo przez developerów Merba). Jest też plik PDF Meet Merb oraz tworzona przez internautów Life On The Edge With Merb, DataMapper & RSpec. Zaś dzięki temu że Merb jest w wielu sprawach wzorowany i bardzo podobny do Rails, ci co zainwestowali w naukę Rails, będą mieli dużo łatwiej jeśli chodzi o opanowanie Merba. Moim zdaniem dobrze znać oba te frameworki.

JRuby – nowe perspektywy

Promowany przez Merba, ciekawie zapowiadający się ORMDataMapper (pozwala m.in. zupełnie odizolować bazę od modelu ORM i np. dane pobierać z wielu źródeł) jeszcze nie osiągnął wersji 1.0, ale z dobrze poinformowanych plotek ;) od stycznia DataMapper ma się przestawić głównie na JRuby. Jeśli tak się naprawdę stanie, to być może JRuby stanie priorytetową platformą także dla samego Merba (co by mi się bardzo podobało, wolę np. pisać rozszerzenia w Javie niż w C).

Co prawda Rails działa też z JRuby, ale “JRuby on Merb”, z racji dużo mniejszej ilości warstw pośrednich i większych optymalizacji, powinien uzyskać dużo większe przyśpieszenie w stos do “JRuby on Rails”. Oczywiście już teraz Merb oparty na Ruby Enterprise jest mniej więcej 3-5x szybszy od Rails. To, co jednak najbardziej jest istotne w użyciu JRuby zamiast CRuby to dostęp do dojrzałych rozwiązań dla platformy Javy.

Do tej pory miłośnicy Ruby’ego mogli tylko zazdrościć fanom Pythona którzy mają obiektowy serwer aplikacyjny z prawdziwego zdarzenia – Zope który korzysta z prawdziwej, obiektowej bazy danych ZODB (napisanej zresztą też w Pythonie). Obiektowa baza danych to zupełnie “inna półka” w porównaniu do wszystkich ORM’ów, które mniej lub bardziej udanie naśladują bazę obiektową (tak naprawdę muszą pracować z płaskim, dwuwymiarowymi tabelami relacyjnych baz danych). Dzięki JRuby nie powinno być problemu z odpaleniem Merba na prawdziwej obiektowej bazie danych takiej jak np. bardzo szybka db4o (Kacper Cieśla w swoim blogu przedstawił proof of concept takiego rozwiązania).

Ale to nie wszystko co jeszcze można osiągnąć. Parę miesięcy temu pisałem o Maglev’ie próbie uruchomienia Ruby’ego na wirtualnej maszynie stworzonej pierwotnie dla Smalltalka. Jak na razie nie wiadomo kiedy to rozwiązanie będzie na tyle dopracowanem aby można było na nim uruchomić produkcyjnie Rails czy Merba. Zaś dzięki JRuby już teraz można pokusić się o eksperymenty z rozwiązaniem podobnym do Gemstone i Maglev’a. Chodzi o projekty takie jak GridGain czy Terracota. (zobacz wpis w blogu Fabio Kunga).

Wyobraźmy sobie, co to zmienia w pisaniu kodu. Zero tabel, indeksów, skomplikowanych joinów. Zamiast tego mamy dostęp do nieulotnej pamięci operacyjnej rozpostartej przezroczyście na wiele różnych komputerów. Nie trzeba nic zapisywać na dysku, trwałość obiektów jest tworzona automatycznie przez Terracotę.

JRuby wydaje się więc być dobrym kierunkiem dla frameworków Ruby’ego. Kto wie, może w końcu doczekamy się “rubinowej” odpowiedzi na pythonowy Zope 3? JRuby z obiektową bazą db4o lub na platformie typu Terracota, to byłby całkiem poważny gracz na rynku którego nikt nie mógłby lekceważyć.

Tagi , , , , , ,  | 32 comments

Comments

  1. Avatar Radarek powiedział about 8 hours later:

    Demagogię siejesz w kwestii DataMappera <=> JRuby ;). Nie wiem co dokładnie developerzy DM powiedzieli. Wydaje mi się, że mogli mieć na myśli to, że bardziej przyłożą się do implementacji DataSources ze świata Javy (np db4o). Bo innej tutaj możliwości nie widzę, przecież DM to zwykły kod Rubiego…

    JRuby raczej nie stanie się priorytetową platformą dla Merba. Bądźmy szczerzy, JRuby jest raczej adresowane do programistów Javy, którzy chcieliby także coś poprogramować w Rubym. “Fanatycy” Rubiego (których jest większość) pozostaną raczej przy “oryginalnym” MRI. Żeby efektownie korzystać z JRubiego trzeba raczej znać Javę i tego nie da się łatwo przeskoczyć.

  2. Avatar Jarosław Zabiełło powiedział about 9 hours later:

    @Radarek: Zajrzyj do wczorajszych logów kanału #rubyonrails. Lopex napisał, że na kanał #jruby wpadł jeden z developerów DataMappera i zapowiedział że od stycznia chcą przejść na JRuby. Nie wiem na ile to pewne, dlatego nazwałem to “dobrze poinformowaną plotką”. ;) Ale pożyjemy, zobaczymy. Widząc perturbacje z kompletnie nieudaną wersją CRuby 1.8.7, myślę że JRuby to dobry kierunek rozwoju dla Merba i Rails.

    Nie zgodzę się z Tobą, że do używania JRuby w Merbie (czy Rails), trzeba znać Javę na jakimś niebotycznym (“nie do przeskoczenia”) poziomie. Po pierwsze, Java jest dużo prostszym językiem od Ruby’ego. Po drugie, o ile nie używasz jakichś specjalnych bibliotek Javy (co w JRuby jest i tak proste), to praca z JRuby on Rails niczym specjalnym się nie różni od CRuby on Rails.

  3. Avatar Uzytkownik powiedział about 9 hours later:

    > to praca z JRuby on Rails niczym specjalnym się nie różni od CRuby on Rails.

    To na czym miałoby polegać przejście?

  4. Avatar Radarek powiedział about 9 hours later:

    “Nie zgodzę się z Tobą, że do używania JRuby w Merbie (czy Rails), trzeba znać Javę na jakimś niebotycznym (“nie do przeskoczenia”) poziomie.”

    Języka możesz nie znać w ogóle, tu chodzi o całą platformę jvm. Sam język jest dosyć prosty (tu się zgodzę, że o wiele prostszy od Rubiego), ale jvm jako platforma jest już o wiele bardziej skomplikowana od tego do czego jesteśmy przyzwyczajeni w przypadku Rubiegiego.

  5. Avatar Paweł Kondzior powiedział about 9 hours later:

    A ja mam tylko nadzieje ze Merb wcale nie chce walczyć z Rails. Wolal bym raczej aby Merb przyciagnal do srodowiska ruby jeszcze wieksza rzesze programistow, a JRuby jeszcze wieksza rzesze programistow javy :-) To troche infantylne ogolnie, pozorowanie takiej wojny miedzy tymi dwoma framworkami.

    Pozatym nie dokonca rozumiem co ten developer DM mogl miec na mysli. Poniewz JRuby chyba zalezy na tym aby byc jaknajbardziej zgodnym z implementacja CRuby (1.8.6 i 1.9.0) a jesli sa to szczere intencje i beda konsekwentnie wdrazane to nie widze powodu aby mialo znaczenie to czego ci developerzy DM uzywaja do rozwoju swojego ormika. A jesli przyjdzie taki dzien w ktorym jakies wydanie DM okaze sie niekompatybilne z cruby, to sadze ze spotka ich dosyc surowa krytyka z ramienia uzytkownikow cruby ;P i skonczy sie na tym ze i tak pojda po rozum do glowy.

    Wogole :) skad tyle ostatnio w was nienawisci do AR i ogolnie ORM’ow ? (to oczywiscie mala prowokacja ale zauwazylem pewien trend u kilku osob do jechania po dosyc dojrzalej bibliotece w ruby na rzecz niedokonca dojrzalego db4o w JRuby [i nie mam na mysli niedojrzalosci javy, tylko wsparcie db4o po stronie ruby])

    Jestem pod wrazeniem obiektowych baz danych, zapowiadaja sie jako bazy szybsze, o wiekszej elastycznosci i mozliwosciach formowania bardzo skomplikowanych struktur danych. Jednak jest to zupelnie inne podejscie do rdbms i napotyka zupelnie inne problemy. Np w db4o 90 MB plik bazy w pamieci bedzie zajmowal 900 mega ;) (o szczegoly trzeba by sie zapytac dmiltith’a poniewaz to on akurat chyba bawi sie w testowanie tego srodowiska)

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

    @Uzytkownik: nie wiem czy tak naprawdę DM skupi się tylko na JRuby (obu nie). Zasadnicza różnica to wygodny dostęp do bibliotek Javy.

    @Radarek: Java jako platforma jest skomplikowana ale nikt nie każe ci korzystać z całego J2EE. :) Chodzi raczej o dostęp do niektórych rzeczy, a to nie jest strasznie trudne. Np. JRuby (dzięki dojrzałemu driverowi JDBC) rozwiązał mi problem komunikacji z bazą Oracle pod Linuksem i OSX. Także pisanie rozszerzeń przyśpieszających jakieś kluczowe punkty aplikacji jest łatwiejsze w Javie niż w C. Co do złożoności, to zobacz jak bardzo Rails się rozbudował i skomplikował w stosunku do wersji 1.0…

    @Paweł Kondzior: nie wiem czy użycie OODB musi pociągać za sobą jakieś dramatycznie większe zużycie pamięci. Jeśli chodzi o AR, to pomijając jego chamskie wstawki SQL’a, ogólnie jest wolny (w w wypadku Oracle’a który bardzo preferuje używanie prepared statements, jeszcze wolniejszy). DataMapper zaś ma _prepared statements). Na pewno użycie JRuby z db4o to świeża sprawa i ewentualne trudności wyjdą w praktyce, ale na pewno jest to ciekawa alternatywa do poeksperymentowania.

  7. Avatar szymon powiedział about 11 hours later:

    To takie małe pytanie: robiłem malutkie testy aplikacji opartych na ROR, merbie i django. Zużycie pamięci jest ogromne w wykonaniu RORa, django i merb mają podobne wyniki. 1. Czy merb nadaje się produkcyjnie do czegokolwiek? 2. Jaka jest zależność zużycia pamięci i liczby obsługiwanych requestów w ROR czy merbie w rzeczywistej aplikacji?

    Stoję obecnie przed problemem przekonaniu kilku osób, że mogą mieć lepsze strony www, będą robione inaczej niż ich obecne w php. Problemem jest to, że serwery, które mają wykupione, nie są takie tanie, za to są bardzo obciążone, głównie pocztą i ftpem. Strona zrobiona w php wykorzystuje naprawdę o wiele mniej zasobów niż to samow w ROR. Więc takie proste pytanie: czy warto i co się dostaje w zamian.

    No i jeszcze odnośnie tych obiektowych baz danych: fajne to jeśli jest jakaś symboliczna liczba tych obiektów. Jakoś nie widzę dużej wydajności takiej bazy chociażby w prostym cmsie w którym mamy jakieś 200-300tys artykułów z przyrostem ok 5tys miesięcznie.

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

    Warto napewno nie tworzyc aplikacji w php :) chyba ze ktos szuka kiepskich i tanich programistow. Jesli chodzi o zuzycie pamieci w przypadku rails to faktycznie, uzywjac mongrela i ruby 1.8.6 nie jest rozowo. Ale REE i mod_rails(mod_rack?) aka mod_passenger oferuja znacznie mniejsze zycie pamieci.

    Jesli chodzi o wydajnosc takie cms’a to testowalismy np sortowanie tabel / obiektow po 100 tys i pobranie 100 % posrotowanych rekrdow vs bylo tak samo wydajne jak posorotwanie 100 tys obiektow. Z tym ze orownywalismy zapytanie do bazy z bezposrednim pobranie obiektow. A wiec gdyby wykorzystac teraz ORM bylo by to dramatycznie wolniejsze w przypadku RDBMS.

    Napewno ORM’y to okres przejsciowy, pomost pomiedzy rdbms i odbms i wydaje mi sie ze dobrze zaprojektowana warstwa aplikacji w ORM oferuje swobodne przejscie do obiektowej bazy danych w przyszlosci :) Tylko podkreslam i pogrubiam, musi to byc dobrze zaprojektowana baza oraz modele ktore wystawiaja tylko api do kontrolerow. Chociaz podejrzewam ze nie bylo by tak ciezko zbudowac wrapper AR find() na DB4O w merbie. Ale taki wrapper trzeba by oczywiscie traktowac tez jako rozwiazanie posrednie, tylko napewien okres czasu.

  9. Avatar szymon powiedział about 11 hours later:

    “znacznie mniejsze zużycie pamięci” czyli ile? liczymy to dalej w setkach megabajtów czy już dziesiątkach? W efekcie takich małoefektywnych zabaw, dostajemy wysokie koszty sprzętu w porównaniu z takim phpem, przez co takie rozwiązania łatwo przegrywają u managerów.

    ORM jest fajny dla małych aplikacji, jak masz coś większego to zaczyna się optymalizacja w postaci używania nieprzenośnych rozwiązań, typów danych czy wręcz tego co zaleca każdy ORM: “jak jest niewydajnie, to napisz sobie SQLa ręcznie”.

  10. Avatar Paweł Kondzior powiedział about 12 hours later:

    Sporo agresji w towim poscie ;) Ale skoro jestes na tyle leniwy aby sprawdzic co to jest REE no to zajrzyj tutaj http://www.rubyenterpriseedition.com/comparisons.html Zyjemy w czasach gdy 4 gb ramu kosztuje 50 dolarow. Godzina pracy programisty kosztuje pewnie srednio 20-40 dolarow. Ja liczyc nie musze, wiem ze pehape sie nie nadaje juz do zadnych zastosowan bo swiat poszedl naprzod, java, .net, python, ruby rozwinely swoje frameworki. PHP pozostanie jezykiem proceduralnym… i nie wazne jak bardzo framework w php bedzie obiektowy i tak bedzie wyglada jak syfna sieka. Ten jezyk nie jest w stanie sie rozwijac… bo jego developerzy bladzal (poczytaj: http://ninh.nl/blog/2008/10/25/a-word-on-phps-upcoming-namespace-seperator/)

    Java tez wymaga duzo pamieci ;] naszczescie jest szybsza. Managerowie i tak ja wybieraja.

    Hibernate albo Ibatis tez jest do malych aplikacji ? Sorry ale chyba nie wiesz o czym mowisz jesli uwazasz ze ORM jest dla malych aplikacji. ORM sluzy do MAPOWANI relacyjnej bazy danych na obiekty. Wiekszosc ORM’ow pozwala na tworzenie wlasnych zapytan i budowanie relacji/obiektow poprzez wlasne zapytania.

  11. Avatar szymon powiedział about 12 hours later:

    hm… ja wiem czy agresji… czepiam się jak zwykle :)

    REE – jakoś do tego nie dotarłem szukając różnych benchmarków, wiem, wstyd się przyznać.

    To, że PHP się nie będzie rozwijał to oczywiste, a przynajmniej nie w kierunku, który jest przemyślany.

    Jeśli chodzi o javę i managerów, to sprawa jest oczywista: jest niezły support (przynajmniej tak myślą) i bezpieczniej jest im wybierać javę.

    Hibernate i Ibatis… przecież to właśnie dokumentacji do Hibernate’a jest napisane, że jak zapytania są naprawdę wolne i nie da się tego normalnie poprawić, to najlepiej przepisać to w SQLu i odpalić w czystym JDBC. ORM jest super dla małych aplikacji, dla większych okazuje się, że trzeba pisać ręcznie SQLa i stosować inne zabiegi. Kwestia tego co rozumiemy pod pojęciem małej aplikacji.

    Ogólnie to szukam argumentów na to że lepiej bawić się w RORa niż coś innego, argumentów, które przekonają różnych manago i ludzi, którzy mają na to wyłożyć kasę.

  12. Avatar Jarosław Zabiełło powiedział about 13 hours later:

    @szymon: a musi być RoR a nie Merb? :) Tu masz skrócie to, co oferuje Merb: http://merbist.com/2008/11/09/merb-1-0-released/. Dodatkowe źródła o Merbie: 44 Merb resources.

    A co do szybkości, to frameworki napisane w PHP (włacznie z ponoć najszybszym Icogniterem) są wyraźnie wolniejsze w stosunku do frameworków w Ruby (włącznie z RoR, który dawno temu może był wolniejszy, ale nie teraz). Merb zaś deklasuje ich wszystkich jeśli chodzi o wydajność, rzecz jasna. :)

    Co do Javy to dzięki JRuby bardzo łatwo zintegrować RoR czy Merb z istniejącą infrastrukturą w Javie. Pracowałem w JRuby on Rails i działa to bardzo ładnie. Sun nie tylko rozwija JRuby ale też sam używa JRuby i Rails.

    Co do pisania ręcznie SQL, to można to czynić w RoR i Merbie, jak ktoś chce. Żaden problem. Ale znacznie wygodniej zrobić to w Sequelu, który pozwala na krokowe budowanie złożonych zapytań w znacznie wygodniejszy sposób, za pomocą Ruby’ego.

    Ogólnie Rails/Merb to dużo szybsze tworzenie kodu i łatwiejsze jego utrzymanie niż w PHP + dostęp do bibliotek Javy dzięki JRuby (jeśli jest taka potrzeba). To też znacznie lepsze mechanizmy automatycznego testowania kodu (vide: RSpec) niż prymitywny PHPUnit z którym ostatnio mam sporo do czynienia. Ruby to także mniej frustracji i więcej zadowolenia ze strony programistów, bo to był też jedno z założeń podczas tworzenia tego języka.

  13. Avatar Hubert Łępicki powiedział 1 day later:

    Fajnie że Merb osiągnął wersję 1.0… Tak na prawdę znaczenia technologicznie dużego to nie ma, Merb był używalny już od jakiegoś czasu. Znaczenie psychologiczne jest tu jednak nieocenione – można się spodziewać wysypu postów na blogach, książek itd. dotyczących Merba.

    Co do konkurencji z Rails… myślę że już to przynosi pozytywne efekty. Rails 2.2 doczekało się wielowątkowośći – ciekawe czy developerzy Rails by się tym tematem zainteresowali tak sami z siebie (DHH jakiś czas temu mówił że “się nie da”).

    Może i w Polsce popularność RoR/Merb wreszcie skoczy dzięki tym ostatnim nowinkom :).

  14. Avatar szymon powiedział 2 days later:

    Jeszcze tylko do szcześcia potrzeba merbowi dokumentacji (takiej jak ma django), ksiażek, wsparcia w edytorach (ROR ma ładne wsparcie chociażby w netbeansie), tutoriali, dużego community… i będziemy szczęśliwi, a do tego czasu nie wróżę merbowi dobrej przyszłości. Znani mi ludzie jak mieli wybierać w czym pisać, to wybierali głównie django… rzadziej RORa, o merbie prawie nikt nie słyszał.

  15. Avatar jiima powiedział 2 days later:

    @All

    Kilka sprostowań.

    1. PHP nie jest taki straszny jak go malują. Owszem, jest niedopracowany, dziwnie się rozwija, a koszt porządnych narzędzi do niego jak dotąd był dość wysoki (do momentu gdy Zend wypuścił PDT). Poza tym pokutuje bzdurna opinia że PHP jest prosty, więc każdy młotek który opanuje składnię “include” i selekta w MySQL może już w nim pisać. I piszą, czego efekty widać. Twórcy frameworków PHP też się trochę pogubili. Problem jest w tym, że nawet Camping tworzy coś w rodzaju mini – serwera, podczas gdy PHP działa wciąż na modelu CGI (nie mówię o samym PHP który może działać na wiele różnych sposobów, ale typowy projekt napisany w PHP to typowe CGI – wczytaj – stwórz obiekty – odpal – zbierz response – wyczyść pamięć – koniec programa). Dzięki temu PHP jednocześnie ma tak dobre wyniki jeśli chodzi o obciążanie serwera i tak beznadziejne jeśli chodzi o wydajność. Mam wrażenie, że problem leży też gdzieś w implementacji OO. “klasycznie” napisane proceduralne programiki w PHP działają zadziwiająco szybko.

    2. Co do baz obiektowych, nie wiem. Używałem DB4O i jakoś nie jestem przekonany do tej idei – przydał mi się wprawdzie jako backend sesji dla sporej klastrowej aplikacji i działał szybciej niż analogiczny backend z serializacją do bazy danych (Informix), jednak tam wybieranie odbywało się po identyfikatorze obiektu (czyli kluczu głównym) i w zasadzie po niczym innym. Nie wiem jak to by było gdyby cała warstwa obiektów domeny chodziła na tym. Poza tym, @JZ, zauważ że model domeny z reguły jest projektowany z perspektywy paradygmatu relacyjnego. Mało w nim dziedziczenia, sporo agregacji, zwykle nie tworzy się struktur drzewiastych czy jakiś większych grafów. Nie chcę też krakać, ale jakoś bazy obiektowe istnieją już od dawna (słyszałem o nich jakieś 10 lat temu, DB4O używałem 3 lata temu i jakoś nie była to nowość). Smalltalk istniał w latach 80-tych. Do dziś używamy baz pseudo – relacyjnych i języka SQL do gadania z nimi i pewnie tak zostanie jeszcze długo. Vendorzy baz mają w tym interes. Poza tym w Oracle też masz mechanizmy obiektowe, pełną persystencję itp – i powiedz mi, kto właściwie z tego korzysta? To już mój 6 projekt z Oracle i jakoś ani razu nie widziałem użycia typów obiektowych w praktyce… @Szymon ORM są do małych projektów? Nie sądzę. Robiłem naprawdę spory projekt na Hibernate (obsługa ubezpieczeń komunikacyjnych u jednego z gigantów ubezpieczeniowych), teraz siedzę na innym projekcie który używa własnego ORM-a. Owszem, zawsze dochodzi się do momentu gdzie trzeba zakasać rękawy, napisać zapytanie czy odpalić jakąś procedurę składowaną, ale zwykle dotyczy to przypadków brzegowych, jakiś nietypowych agregacji, raportów… 80% kodu będzie korzystać z tego co daje ORM i nie będzie narzekać na wydajność. A chyba lepiej pisać 20% zapytań niż 100. Zwłaszcza że te 80% będzie trywialne i z szablonu. Co do iBatisa to w ogóle dziwne że ta nazwa padła – iBatis nie jest ORM i nie generuje zapytań za programistę, a jedynie dostarcza warstwy ułatwiającej korzystanie z JDBC, które jest nieco rozdęte (w końcu to niemal 1:1 kopia ODBC). Tak więc jeśli korzystasz z iBatisa musisz sam pisać zapytania, chyba że zrobi to za ciebie kolega.

    3. Co do CMS-ów bo mam wrażenie że wiele osób patrzy na aplikacje sieciowe przez ich perspektywę, to myślę że przyszłością dla nich mogą być bazy dokumentowe, takie jak Couch. DM ma nawet adapter do Couch’a. Oczywiście, mówię t konkretnie o CMS-ach gdyż bazy dokumentowe nie nadają się do wszystkich zastosowań…

  16. Avatar szymon powiedział 2 days later:

    @jiima Pisząc, że ORM do małych projektów miałem właśnie na myśli to, że sam ORM nie wystarczas do dużych rzeczy, tak trzeba ręcznie pisać nieprzenośnego na inne bazy SQLa.

  17. Avatar Jarosław Zabiełło powiedział 2 days later:

    @szymon: Użycie ORM nie przeczy użyciu SQL jak jest taka potrzeba. Co prawda, bardziej wyrafinowane ORM’y (Hibernate, SQLAlchemy) potrafią stworzyć dosyć skomplikowane kwerendy, ale wydaje mi się że tu potrzeba równowagi. Czasem użycie czystego SQL jest prostsze po prostu, i nie ma nic niestosownego, aby go użyć mimo korzystania z ORM’a.

    @jiima: Masz w zupełności rację co do PHP. PHP nie jest ani prosty, ani łatwy, ani ładny, ani spójny. Ta jego rzekoma prostota to mit z przeszłości (PHP3?) Współczesny PHP5 ze swoją składnią wzorowaną na C+ i Perlu (IMHO to raczej chore wzorce do naśladowania). Ze swymi trzema różnymi interfejsami do MySQL (mysql, mysqli, pdo), bez przestrzeni nazw, bez możliwości kaskadowego wywoływania metod (nawet Java potrafi new Obj()>metoda1>metoda2()), bez wyjątków na poziomie wszystkich funkcji (niestety podstawowe funkcje są wciąż proceduralne, chaotyczne i nie generują wyjątków w razie błędu), czy nawet bez porządnej biblioteki do automatycznego testowania (PHPUnit to żenada), PHP jest językiem po prostu trudnym i uciążliwym w użyciu.

    Co do baz obiektowych (czy rozwiązań transparentnych takich jak Maglev), to wymagają zmiany sposobu myślenia przy projektowaniu aplikacji. Ale można, co widać po Zope czy Plone. Oracle może i ma jakieś mechanizmy obiektowe (zdaje się że PostgreSQL miał je wcześniej) ale to raczej nie to samo, co prawdziwa obiektowa baza danych.

  18. Avatar szymon powiedział 3 days later:

    @Jarek Tak odnośnie sequela: jak wpisać port bazy w konfigu tak żeby merb się połączył? Ja tam się bardzo na tym nie znam, ale nie widziałem żadnego przykładu, w którym byłby podany port, a przeglądając pliki sequela, też nie znalazłem żadnej wzmianki na ten temat.

  19. Avatar Jarosław Zabiełło powiedział 4 days later:

    @szymon: Obawiam się że to problem nie tyle Merba co Sequel’a. Właśnie zgłosiłem im ten błąd.

  20. Avatar szymon powiedział 4 days later:

    @Jarek:

    ładne zgłoszenie… to ja się dopisałem odnośnie Postgresa

  21. Avatar Nowaker powiedział 4 days later:

    Jako programista PHP ubolewam nad kierunkiem rozwoju PHP (cofaniem się?). Przeszedłbym na inną platformę, gdyby nie fakt, że mam już pokaźny zbiór modułów do frameworka i gdy chodzi o szybkie wyprodukowanie aplikacji, to jednak najszybciej dostaję to, co chcę właśnie w PHP.

    Chciałbym tylko sprostować wypowiedź, że w PHP nie ma chainingu. $obiekt->metoda()->metoda_inna() oczywiście jest. Nie działa chaining w powiązaniu z new, to fakt.

    Aczkolwiek wcale nie neguję kiepskiej jakości PHP. Zwykłe errory zamiast Exception. Spójność nazewnictwa: filemtime(), file_exists() i PDOStatement. Wydajność, enkodery płatne, CGI. Ech…

    P.S. Wywal ten domyślny gravatar, bo wprowadza nieład – różne osoby mają ten sam avatar i wygląda, jak by to jedna osoba pisała.

  22. Avatar szymon powiedział 4 days later:

    PHP ma też zalety: tani hosting, strona napisana w PHP jest często tańsza w utrzymaniu. Sam widziałem chociażby serwis ogłoszeniowy z kilkoma milionami ogłoszeń, który przeszedł z Javy na PHP i się z tego cieszyli. Sam zresztą zaczynałem robienie sajtów w PHP i cały czas mnie bolał koszmarny model obiektowy. Teraz ludzie zachwycają się pythonem, w którym wszystkie pola w klasie są publiczne i nikomu to nie przeszkadza.

  23. Avatar Jiima powiedział 6 days later:

    @Szymon

    A ja powiem coś dokładnie odwrotnego niż ty – ORM jest właśnie do większych projektów. Przykłady? Proszę – raz to przepisywanie “pure-JDBC” na iBatisa, a potem na Hibernate stopniowo rozdymanej aplikacji enterprise, przerabiałem to ze dwa razy. Dwa to mój ostatni prywatny projekcik. Uparłem się jechać na czystym DB api, dopóki model mi się nie skomplikował. Potem wywaliłem wszystko do kosza i zacząłem z ORM, bo na myśl o pisaniu kolejnej kwerendy dostawałem mdłości.

    W dużym projekcie (jakieś 100 klas domeny) potniesz się a nie napiszesz to w czystym DB api. Chociażby dlatego, że większość znanych mi interfejsów bazodanowych (bez względu na język) operuje na kursorach, ew. na rozłączonych datasetach (co sprawdza się tylko dla małych porcji danych, czego boleśnie uczy się niejeden zagorzały fan C#). Większość programistów jednak woli operować nie na kursorach i datasetach (które są tak naprawdę podrasowanymi hashtable’ami) tylko na obiektach. Co więcej, większość zapytań i mapowań naprawdę jest tak łopatologiczna, że spokojnie można to powierzyć maszynie (ORM). Pozostają zwykle przypadki skrajne, które trzeba rzeźbić w jakimś OQL’u (większość ORMów ma jakiś) lub w czystym SQL, ale to są przypadki brzegowe – raporty, złożone zestawienia, podsumowania itp. W efekcie piszesz na przykład 20 zapytań, a nie 200, z czego większość i tak byś pisał przez copy-paste bo jest powtarzalna. ORM dostarcza zwykle całej masy pobocznych usług. Dlaczego wolę na przykład użyć “native query” w Hibernate czy Doctrine(PHP), zamiast używać DB Api? Głównie dlatego, że jeszcze nie spotkałem sensownego DB Api. Większość stanowi niezbyt udolne mapowanie natywnego sterownika do bazy (napisanego zwykle w C) na konkretny język. Python tu ma chyba najlepiej rozwiązane API, bo na przykład takie JDBC to “uobiektowione” ODBC, o interfejsach bazodanowych w PHP i Ruby się nie wypowiadam (w obydwu językach panuje po prostu wolna amerykanka, w Ruby przynajmniej jest ona obiektowa…). Tymczasem zapytanie natywne w takim Hibernate oszczędza mi użerania się z JDBC i jeszcze wykona mapowanie dataseta na obiekty domeny.

    @JZ

    Owszem, to wymaga zmiany sposobu myślenia, ale nie twojego czy mojego (jak zapewne zauważyłeś jestem dość otwarty na nowinki i nie przekreślam żadnej technologii dopóki mnie czymś wyjątkowo nie wkurzy), tylko szefów firm. Ci z reguły mają kupionego za ciężkie pieniądze Oracle’a i tego Oracle’a (czy innego MSSQL) trzeba użyć, bo na przykład 10 innych systemów go też używa. Nawet Squeak i Dolphin Smalltalk mają interfejsy do baz relacyjnych, a przecież Smalltalk to ostatni język w którym potrzebna jest relacyjna baza danych.

    Co do Perla, będę go bronił do ostatniej kropli krwi, nie znam żadnego języka w którym tak łatwo się metaprogramuje, oprócz oczywiście Ruby. Problem nie stanowi Perl, lecz “Just Another Perl Hackers”, którzy za szczyt ambicji poczytują sobie stworzenie kodu który tylko oni rozumieją i wmawiają wszystkim dookoła że jak napiszesz przejrzysty i czytelny program w Perlu (vide Catalyst) to nie jesteś prawdziwym programistą Perla. No cóż, zboczenia są różne, w Brainf*cku też niektórzy piszą.

    Natomiast co do PHP, jego podobieństwo do Perla jest pozorne i wygląda “jak sobie mały Kazio wyobraża”. Np. w Perlu mamy funkcje anonimowe i domknięcia a def jest operatorem. W PHP jedyny sposób na stworzenie anonimowej funkcji nie zasługuje na wspomnienie, bo po co się pastwić? w PHP 5.3 ma się to zmienić (namespacing, lambdy) ale wciąż jest w wersji alfa, więc jak dla mnie nie istnieje.

    Za to zgadzam się z wadami w zupełności, poza chainingiem – jest jak najbardziej możliwy, choć przez pewne naleciałości ze starszych wersji (jak zwykle) da się napisać metodę tak, że to nie zadziała… Poza tym rzeczywiście skojarzenie z C++ jest stosowne – też obiektowość i wyjątki trochę na siłę, dziwaczne reflection i frameworki powstające tylko po to by przykryć wady języka (jak Qt w C++). Za to rzeczywiście da się go łatwo postawić no i model CGI wykonania skryptów załatwia nam problemy z pamięcią.

    Dla fanów “mało zasobożernego PHP”, proponuję przepisać Merba w PHP, tak by działało jako niezależny serwer – to wbrew pozorom jest wykonalne, obecnie PHP ma wszystkie wymagane narzędzia by zrobić to w miarę sensownie i czytelnie. Pytanie, czy nadal będzie tak mało pamięciożerny. Obawiam się że nie, wprost przeciwnie. Nie wiem jak wydajny jest mechanizm odśmiecania w PHP, ale podejrzewam że słabo (w końcu i tak na koniec zabawy usuwamy wszystko), co oznacza że taki serwerek zeżre conajmniej tyle samo pamięci co ten w Ruby…

  24. Avatar Krzysiek powiedział 8 days later:

    ok, a tak na wyższym poziomie troche – czy jest jakiś sensowny engine do modelowania procesów biznesowych, który się sprzęga z railsami?

    miałem ostatnio przyjemność zagłębić się chwilę dłużej w seam (jbpm + jsf + drools + ejb +...) i na dłuższą metę przy większych rzeczach trudno jest zarządzać flow’em inaczej niż w taki sposób.

  25. Avatar jiima powiedział 8 days later:

    @Krzysiek

    Nie słyszałem o niczym takim, z resztą JBPM też nie jest specjalnie potrzebny w większości zastosowań, o Drools nie wspominając. Żeby naprawdę potrzebować BPM, to musimy mieć nie “większą rzecz” tylko “naprawdę dużą”. To, co by się w Rails / Merbie / Ramaze przydało natomiast (podobnie jak w wielu innych środowiskach) to “flow scope” podobny do tego w Seam. Jak przekonałem się jednak na własnej skórze (pisząc coś takiego dla Stripes) nie jest to wbrew pozorom trywialne… Rails idzie raczej w stronę rozwiązań bezstanowych i AJAX-a (dowodem na to może być użycie idiotycznego Cookie Store jako domyślnej implementacji sesji w R2.0) i unikania stanowości tak długo jak to możliwe. Jest coś takiego jak openwferu.rubyforge.org, obejrzyj sobie to jak jesteś zainteresowany, nie bawiłem się tym więc nie wiem czy jest sensowne.

  26. Avatar tomek powiedział 18 days later:

    Terracota – po prostu nie działa, próbowaliśmy wdrożyć to w firmie ale trzeba przepisać całe masy kodu. Nie jest to rozwiązanie przezroczyste ani proste do wdrożenia. Trzeba pisac aplikację pod Terracote – inaczej nie będzie działać

    db4o – idealnie nadaje się do wbudowania w aplikację. Nie pociągnie strony internetowej z większym ruchem.

  27. Avatar szymon powiedział 29 days later:

    @Jarek

    Zgłosiłeś ten błąd, został całkowicie olany poprzez #SOA1. Zaktualizowałem sobie merba, zrobiłem projekt z sequelem… i co? I nic. W konfiguracji mam port: 5830, a potem coś takiego:

    $rake sequel:db:migrate —ble ble ble -- could not connect to server: Connection refused Is the server running on host “localhost” and accepting TCP/IP connections on port 5432?

    Cóż, pełna dyskwalifikacja po raz kolejny, idę obejrzeć jak działa merb z datamapperem.

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

    @szymon: Z tego co napisał Jeremy Evans wynika, że problem dotyczy tylko MySQL a nie PostgreSQL (sprawdź najnowszą wersję Sequela). A co do MySQL, to nie jest to problem Sequela, ale biblioteki ruby-mysql. Napisał aby zgłosić problem twórcom ruby-mysql.

  29. Avatar szymon powiedział 29 days later:

    Sequel jest najnowszy, dla MySQLa tego w ogóle nie sprawdzałem, bo nie używam. Nie testowałem wszystkich możliwych bibliotek, które po kolei są wywoływane, interesuje mnie to, że merb z tym nie działa. Mam u siebie lokalnie zainstalowane jakieś 12 instancji Postgresa, nie mam zamiaru przekonfigurowywać sobie wszystkiego tylko po to żeby chodziło to na konkretnym porcie, bo merb inaczej nie umie. Idę pobawić się Railsami, może tam cokolwiek działa.

  30. Avatar Jarosław Zabiełło powiedział 29 days later:

    Merb nie ma tu nic do rzeczy bo to problem ORM’a jeśli już. Rails ci nic nie pomoże, bo za pracę z bazą jest tam odpowiedzialny ActiveRecord, a jego możesz używać też i w Merbie (lub w dowolnym skrypcie Ruby’ego). Próbowałeś nawiązać połaczenie za z shella za pomocą skryptu sequel?

  31. Avatar szymon powiedział about 1 month later:

    To JEST problem merba, bo jakoś wywołanie sequela z poziomu konsoli działa:

    
    $sequel postgres://[email protected]:5830/gp
    Your database is stored in DB...
    irb(main):001:0> 
    
    $sequel postgres://[email protected]:5831/gp
    could not connect to server: Connection refused
        Is the server running on host "localhost" and accepting
        TCP/IP connections on port 5831?
    

    I wszystko jest OK.

    Próba w merbie:
    
    conf/database.yml
      1 ---
      2 # This is a sample database file for the Sequel ORM
      3 :development: &defaults
      4   :adapter: postgres
      5   :database: gp
      6   :username: gp
      7   :password: gp
      8   :host: localhost
      9   :port: 5830
    
    $ rake sequel:db:migrate
     ~ Connecting to the 'gp' database on 'localhost' using 'postgres' ...
     ~ Parent pid: 27873
     ~ SELECT * FROM "test" LIMIT 1
     ~ could not connect to server: Connection refused
        Is the server running on host "localhost" and accepting
        TCP/IP connections on port 5432?
    
  32. Avatar Jarosław Zabiełło powiedział about 1 month later:

    Do formatowania używa się tu zasad Textile. Poprawiłem ci w tekście (drugi, powtórzony usunąłem.) Co do merb_sequel bo ten gem jest za to odpowiedzialny, to z tego co widzę na liście dostępnych opcji połączenia nie ma w ogóle opcji dla portu. Ruby nie ma named parameters więc czy wpiszesz ‘port’, czy ‘blah’, nie będzie błędu (opcje to Hash) ale też nie będzie żadnej różnicy. To jest najwyraźniej błąd w tym pluginie.

    Sprawdziłem przed chwilką Dodałem ticket na Lighthouse i przypisałem go do twórcy tego pluginu.

(leave url/email »)

   Pomoc języka formatowania Obejrzyj komentarz