Ruby & Ruby On Rails - wasze opinie

0

Hej.

Ostatnio słyszałem dość sporo opinii na temat RoR. Pozytywne ale wydaje mi się że subiektywne i jednostronne. Jakie waszym zdaniem ta technologia ma plusy i minusy? Jakie są wasze doświadczenia z tym językiem i frameworkiem? Czy warto się tego uczyć?

0

To jest tak, że ja jestem bardzo pozytywnie nastawiony na Rubiego. Wiele osób narzeka na Monkey Patche, ale bez nich nie mogło by powstać tak wspaniałe narzędzie jakim jest RSpec. Ja trochę w nim piszę i uważam, że jest bardzo dobre.

Jeśli chodzi o wymienianie plusów i minusów to:
Na plus idzie:

  • RSpec i Cucumber
  • Szybkość pisania dzięki generatorom
  • RubyGems
  • Devise
  • MVC
  • Heroku

Na minus:

  • Wolniejsze niż Java/Scala/Python
  • W Rubym 1.8 i starszych były problemy z wielowątkowością
  • Większość narzędzi developerskich jest nastawiona na Maki i ewentualnie inne *niksy, Windowsem raczej się nie przejmujemy (dla mnie to nie wada, ale zawsze)
0

no i chyba na plus można zaliczyć środowisko (ludzi) - jak się ogląda np oferty pracy dla RoR to rzadko jest brak widełek - patrzec na polskie forum RoR. No i programistów ror jest raczej nieco mniej więc i zarobki ciut wyższe.

0

Sama idea ruby on rails jest ogólnie fajna... Problem w tym że developerzy gemów czasami prześcigają się w głupich pomysłach. Przykłady:

  • Do testów mamy wiele możliwości - nie ma standardu, ale powiedzmy że lubimy albo Test::Unit albo RSpec. chcemy sprawdzić czy wszystko ładnie pieknie działa, w końcu wszyscy w RoR kochają testy, no i mamy kwiatki: testy potwfią się sypnąć tylko dlatego że masz verbose output. Wyłączysz, to innych paczek się sypną o to że nie masz verbose output. sweet.
  • Mamy sobie Ruby, JRuby, RubyEE. załóżmy że każde z nich w wersji 1.9, powinny być zgodne. Nie są. 60%gemów działa na Ruby, 35% na JRuby, a 5% specjalnie pisane pod EE sweet...
  • Hipsterskie wersjonowanie: mamy sobie gem w wersji dumnej 1.2.3. Pełno w nim bugów, trochę twórca nie pomyślał (ach to agile) że z gema będzie korzystać ktoś jeszcze i trzeba by przebudować ciut gem żeby się do czegoś nadawał. Czyli zmieniamy nazwy, parametry wywołania itp itd, ogólnie psując wszystko po drodze. I nowa wersja: 1.2.4
  • Hispterskie zależności: Oczywiście RoR to nie wynajdowanie koła od nowa, czyli jak coś już jest zrobione, to zależność ustawiamy i gotowe. Powiedzmy teraz tak: robimy sobie aplikacje na RoR, potrzebujemy jakiegoś sexy gema w najnowszej wersji. Nie ma problemu gem X v 1.2.4. Ma dependency na Y wersja 0.8.9 (Y teraz jest w wersji 2.7.10) i na Z w wersji 1.5 (a Z mamy teraz w wersji 1.9). Teraz lepsza bajka - Z >=1.6 jest zależne od Y >=2.5. Pięknie. Rozwiązanie - branch na githubie własny do gema X. Prośba do upstream o merge, odpowiedź (dosłowny cytat tego co dostałem): "I dn't car efork it yerself an maitain". Sweet.
  • Chcemy sobie przeprowadzić test jednego gema. Wszystko cacy, dependency cacy itp itd... Ale! nie może być znów super: twórca testu wymaga pliku xyz.foo. plik ma w środku dane! gdzie jest plik xyz.foo? Na dysku twórcy i nigdzie indziej. Poszła prośba o ten plik, ale zero odpowiedzi. Zdarza się.
  • Logowanie - o ile każdy sensowny webapp na innych językach loguje do error_log apache, o tyle w RoR nigdy mi się nie udało do tego doprowadzić. Może to ja jestem dziwny, ale logi w dziwnych miejscach to norma la railsów. I jeszcze pierdyliard gemów do custom logów...
  • Gem vs systemowe pakiety: 0 kompatybilności i miliard problemów. W gentoo jest ok - da się przeżyć. W Debianie - jesteś 50 lat za gentoo, w Centos/RHEL - nie liczyłbym na systemowe paczki (w skrócie jeśli Twój provider miejsca używa centos/RHEL jako środowiska, na 99% aplikacja w RoR nie działa i nic się nie da z tym zrobić). Oczywiście jak masz odpowiedni dostęp to zainstalujesz co potrzebujesz z gemów (jak przeżyjesz) . Update systemu i paczek - problem.
  • Maintaining aplikacji, czyli postawisz i powinno działać. Tak nie jest w przypadku RoR. Nigdy. Najdłuższy czas jaki mi działało cokolwiek zrobione w RoR bez ingerencji to redmine, głównie dzięki temu że wszystko co potrzebuje i zależności jakie ma ma zbundlowane ze sobą.

Osobiście cholernie podoba mi się podejście perla - tam jak coś postawisz to działa ślicznie, ale za to język jest tak cholernie nieczytelny (dla mnie) że aż boli. O pythonie się nie wypowiem, bo nie wiem, ale moi znajomi zarzekają się że świetny jest. PHP - jaki jest każdy widzi.

A co do samego RoR i Ruby: język i założenia świetne, jeszcze tylko było by miło jakby wszyscy postępowali zgodnie z założeniami, to by Ruby i Rail wyparły php z programowania webappowego (może kiedyś... lecz nie teraz)

1 użytkowników online, w tym zalogowanych: 0, gości: 1