Witam,
wiadomo że ludzie siedzący w Railsach chwala ten framework (wiele plusów tego frameworka można znaleźć na necie) itd itd. Jednak chciałbym zadać pytanie odwrotne, mianowicie W CZYM RAILSY SĄ SŁABE, czyli ich negatywne (ciemne) strony i do jakiego typu projektów się nie nadają ? Będę bardzo wdzięczny za wasze opinie i wypowiedzi na ten ten temat.
Pozdrawiam,
Kamil
do niedawna największą (moim zdaniem) bolączką railsów było założenie programistów, że cały świat mówi po angielsku - pełne spolszczenie całej aplikacji bywało kłopotliwe. Na szczęście od któregoś z ostatnich wydań jest natywne i18n, które działa całkiem sprawnie.
Wg. mnie railsy są dojrzałym frameworkiem, który nadaje się do praktycznie wszystkiego - nie widzę jedynie sensu wciskania go tam, gdzie chcemy stworzyć tak naprawdę stronę statyczną(czyli robimy 1 kontroler, który ma w widokach napisaną treść, lub wszystko jest cachowane ) - wtedy to przerost formy nad treścią. Dość wkurzające jest to, że jest wybrany jedyny słuszny prototype (choć bogu dzięki powstał projekt jrails, który portuje jquery do railsów) Z tego co widziałem, wymiana ORMa też nie jest taka super bezbolesna - choć tu się mogę mylić, bo mi tam AR odpowiada 
I18n kuleje w Ruby on Rails i w samym Rubim. Zgodnie z założeniami ma się to zmieniać na lepsze wraz z wydaniem 1.9.1, nie rozwiązuje ono jednak wszystkich problemów. Przesiadka na pełne wsparcie dla różnych kodowań znaków będzie długotrwała i bolesna. Pomimo tego, że Ruby 1.9.1 został wydany ponad pół roku temu wciąż jest traktowany przez społeczność po macoszemu.
Wspomniana przez Tomasha mała modularność RoR spowodowała, że ludzie piszący różnego rodzaju pluginy przyzwyczaili się do nadmiernego stosowania monkey-patchingu (często dlatego, że nie dało się inaczej, czasem aby “odciążyć” programistę od napisania kilku dodatkowych linijek i dorównać ilością stosowanej magii samemu frameworkowi).
Z mniej istotnych problemów - od samego początku nie podobało mi się przywiązanie RoR do Prototype i stosowanie JavaScriptu inline. Zapewne miało to znaczenie czysto marketingowe jako “natywne wsparcie dla AJAX-u”. Wg mnie wszystkie powiązania z bibliotekami JavaScriptowymi powinny zostać wydzielone do zewnętrznych bibliotek. Railsy nie powinny ułatwiać stosowania złych praktyk programistycznych (do tego służą PHP czy ASP ).
aha, ja ze swojej strony dodam jeszcze coś, co mnie osobiście najbardziej boli w codziennej pracy: kulejący scaffold- djangowy generator panelu admina zjada domyślny scaffold railsowy, w sumie active scaffold tez;) mam nadzieje, że to się poprawi w railsach 3
I oczywiście podpisuję się pod I18n i brakiem wypasionego autoadmina 
Tomash: od kiedy jest passenger, to ja bym powiedział, że dodanie aplikacji do podkatalogu jest raczej banalne
A co sadzicie o wydajnosci ? Mam na mysli jakies wieksze przetwarzanie bazy danych. Czy w tym wypadku nie lepiej sprawdza sie .asp ?
Wydajność nie wydajność, tu chodzi o coś innego (aczkolwiek z wydajnością jest coraz lepiej: http://evand.org/2009/02/04/benchmarking-ruby/ ).
Dziś po kilku miesiącach pisania tylko w Rubym usiadłem do projektu w C++ i mam tylko jedno, wielkie, męczące pytanie:
Po co komu średniki?
Wybaczcie OT, ale jak cały projekt kompiluje się kilka minut, to człowieka może szlag trafić.
Mam to samo
Co do wydajności - benchmarkowanie języków skryptowych i frameworków w nich napisanych to zajęcie dla onanistów z mikroskopem. “Wystarczy” pisać z głową, rozsądnie wykorzystać cache, nie tworzyć SQLowych potworków. W ostatniej pracy spotykałem się i jeszcze spotykam systemy np. w php gdzie renderowanie htmla zajmuje 10s gdyż deweloperzy nie znali takich magicznych “sztuczek” jak EXPLAIN ANALYZE i walili w jendym zapytaniu 3 exists, order by random itd. Indeksy źle ustawione albo wcale i zdarzało się że zapytanie wykonywało się 500+ ms. Do wyszukiwarki zamiast full text search napiali zwykłego selecta który zajmował 2 strony w edytorze, a zamiast memcache cachowanie do plików (po nfsie…).
Jeśli w backendzie nie ma kwiatków jak powyższe wystarczy skorzystać z rad Yahoo http://developer.yahoo.com/performance/rules.html i będzie git.
Jeśli chcesz robić grube przetwarzanie danych, to robi się je i tak poza procesem aplikacji/serwera WWW. A w czym to sobie napiszesz, to już należy wyłącznie do Ciebie
Nikt nie napisze o hostingu?
Pewnie dlatego, że problem z hostingiem dla Rails to mit.
Owszem - problem jest z badziewnym hostingiem za 5 złotych rocznie - ale nikt poważny nie korzysta z czegoś takiego do poważnych zastosowań.
VPS, RPS czy serwer dedykowany to bardzo mały fragment budżetu nawet dla niezbyt dużego projektu.
A co z hostingiem? SliceHost jest mega tani, jak chcesz niskich pingów kupujesz dedyka w Polsce (~200zł/mc w OVH) i jedziesz.
Shared hosting raczej nie sprawdza się przy aplikacjach (chyba że masz stronę czysto contentową z dwoma formularzami na krzyż).
Z Passengerem jedyny wymagany skill to umiejętność dodania vhosta do apacha lub nginxa.
Może kiedyś to było problematyczne, ale kiedy zacząłem przygodę z Ruby parę miesięcy temu okazało się to przysłowiową bułką z masłem dla osoby nieco lepiej znającej linuksa, więc nie ma co rozpaczać
Do niedawna miałem aplikację RoR na DreamHost – całkiem “poważną” (sklep internetowy), ponad rok zanim nie przeniosłem na SliceHost. Wpierw na FastCGI, potem Passenger. Można? Można. Działa? Działa! A kosztuje grosze (10$/miesiąc).
@Tomash, z tego co ja widze to najtańszy slicehost to jest 20$ na miesiąc, a 256MB to ledwie wystarcza na system, zatem trzeba 512 slice za 38$ ale większym problemem dla mnie jest że musisz albo sam tym administrować albo nająć admina.
Byłem, robiłem, uprawiałem. Ale skoro wiesz lepiej, to opowiedz mi jeszcze co się da, a czego się nie da na Slice256
To pochwal sie ile zajmował Ci system i ile zostało na aplikacje.
Czy system jakoś specjalnie konfigurowałeś aby był mało ramożerny?
Nie miałeś problemu, że inny user obciąża procesor i twoje zapytania się powoli wykonują?
Miałem tam postawiony Ubuntu Server, na nim apaczyka z Passengerem. Przede wszystkim popularne forum na phpbb (forum.wfb-pol.org) mające ~3k korzystających dziennie (każdy dość sporo hitów) i swój napisany w Railsach sklep (bitspudlo.com). Wszystko chodziło i śmigało, chociaż oczywiście konfiguracja MySQL i Apacza musiała być trochę oszczędniejsza (mniejsze pule procesów, połączeń itd.) niż domyślna (ale to stopniowo sobie tuningowałem). Generalnie chodziło ładnie.
A po upgradzie do Slice512 wrzuciłem tam jeszcze jedną aplikacją Rails (wrug.eu – na mephisto) i trochę innych zabawek (codzienne backupy SQL itd.)
Problemów z obciążeniem nie ma, ponieważ nie jest to hosting dzielony tylko VPS. Masz zagwarantowane, że Twoja część procka i RAMu zawsze będzie dostępna dla Ciebie jeśli Twój proces jej potrzebuje.
To, o czym trzeba pamiętać, to fajna polityka SliceHosta – otóż maszyny nigdy nie są wypełnione do końca. To oznacza, że fizyczny Quad-Core z 16GB RAM (chyba takie maszyny tam mają, chociaż mogę się mylić – ale przycięty o pół giga największy Slice daje pewną wskazówkę) nie jest wyładowany 8-ma Slice2GB czy 32-ma Slice512, zawsze jest zostawione trochę marginesu. To plus niestałe wykorzystanie własnych zasobów przez inne slice’y na tej samej maszynie powoduje, że przez 95% czasu ma się tak naprawdę więcej zasobów niż te gwarantowane.
Ogólnie bardzo dobry pomysł na wystartowanie z Railsami.
Argument o administrowaniu jest w tym przypadku (stawianie aplikacji Rails) nie na miejscu – do deploymentu aplikacji RoR po prostu trzeba znać Linuksa i o wiele więcej się człowiek namęczy i nafrustruje na hostingu dzielonym czy “zarządzanym” niżby sam miał sobie wyjść od gołego systemu. Zazwyczaj (nigdy nie miałem inaczej) mniej czasu zajmuje nauczenie się danego zagadnienia administracyjnego (np. konfiguracja Postfixa i DNSów) niż dopraszanie się “administratora” o zrobienie tego i potem użeranie się z niepoprawną (nieodpowiadającą potrzebom) konfiguracją. O instalowaniu gemów czy możliwości dobierania sobie wersji rubiego (i wszystkich innych narzędzi) wedle własnego widzimisię nawet nie będę wspominał. O procesach w tle (zabronione na hostingach dzielonych) wspomnę, jako że każda aplikacja od pewnego stopnia złożoności ich będzie potrzebować, kropka.
Natomiast z powodu kursu dolara zamiast robić upgrade Slice512 -> Slice1GB, kupiłem dedyka w OVH za 200 PLN/m-c. Jeszcze jestem w trakcie migracji, ale na razie sprawuje się nieźle. Inna sprawa że taki dedyk (“Superplan Mini”) to maszynka na dość profesjonalne już zapotrzebowania
No właśnie ja się zastanawiam również nad migracją ze slicehostu do OVH. Tomash: daj znać jeśli będą z OVH problemy, dla mnie to trochę podejrzanie tanio wygląda :).
Używam ich dedyków od ponad dwóch lat, nie miałem jeszcze powodu, żeby narzekać.
Oczywiście jak się człowiek uprze, to dziura w całym się znajdzie - na tej zasadzie znajomy bardzo na nich narzekał, bo wykupił RPS (coś jak VPS, tyle że nie wirtual, a mały, relatywnie słaby komp z filesystemem po iSCSI) z Debianem (zanim wyszedł Lenny) i bardzo narzekał, że nie wychodzi mu upgrade do testing, i że nie da się wybrać 64-bitowej wersji systemu.