Witam,
Załapałem się ostatnio do pracy przy tworzeniu i rozwijaniu systemów CMS i różnych innych aplikacji webowych. Aktualnie jest to PHP4 i PostgreSQL. To co jest do tej pory napisane jest dość słabe - często zdarzają się dziury (głównie SQL injection), a funkconalność jest bardzo kiepska. Zastanawiam się jakich argumentów użyć, żeby przeforsować używanie railsów.
Na pewno bardzo dobre efekty przy stosunkowo krótkim czasie pracy. Co jeszcze? Bezpieczeństwo? Wydajność?
I jeszcze jedno pytanie. Nie jestem zbyt doświadczony w dobieraniu narzędzi (dodatkowo miałem dość dużą przerwę w pisaniu czegokolwiek), a jak wiadomo jest to duża część sukcesu. Jak railsy sprawdzą się w pisaniu prostych systemów portalowych? Czy framework’i oparte na pythonie (Django, TurboGears) oferują jakieś zalety, których RoR nie ma?
Witam,
Załapałem się ostatnio do pracy przy tworzeniu i rozwijaniu systemów CMS i różnych innych aplikacji webowych. Aktualnie jest to PHP4 i PostgreSQL. To co jest do tej pory napisane jest dość słabe - często zdarzają się dziury (głównie SQL injection), a funkconalność jest bardzo kiepska.
[quote=drogus]Zastanawiam się jakich argumentów użyć, żeby przeforsować używanie railsów.
Na pewno bardzo dobre efekty przy stosunkowo krótkim czasie pracy. Co jeszcze? Bezpieczeństwo? Wydajność?[/quote]
Skalowalność ! Skalowalność
Natomiast musze przyznać że mam duże problemy z dobraniem argumentów które trafią do managmentu.
Może łatwy i sprawny deployment przy użyciu capistrano ?
Wydajność końcowego kodu - raczej nie. Ruby jest wolniejszy od PHP. Ja bym zwrócił uwagę na inne kwestie.
Po pierwsze PHP to nie jest język w pełni obiektowy. Implementacja obiektów w PHP4 jest tak zła, że developerzy załamali ręce. Obiektowość w PHP 5 została napisana kompletnie od zera. Nie dało się poprawić PHP4. Niestety, PHP5 także nie jest w pełni obiektowy. Wciąż brakuje mu podstawowej cechy przestrzeni nazw. To wyklucza go praktycznie z zastosowań do złożonych aplikacji. (Oczywiście można stanąć na rzęsach i próbować pisać w PHP złożone aplikacje, ale ten język do tego się po prostu nie nadaje - łatwo o kolizje funkcji i klas, wręcz nie ma sensu pisać autonomicznych modułów do PHP)
Po drugie, PHP nie jest językiem ogólnego zastosowania. Brak obsługi wielowątkowości wyklucza go jako język do napisania aplikacji standalone. W Pythonie możesz w prosty sposób przenieść aplikację webową do formy offline. Robiłem coś takiego. http://muratordom.pl (który jest napisany w Pythonie) przenosiliśmy do CD. Działało jako demo (MySQL został zastąpiony SQLite, zamiast Apache, wykorzystano wbudowany wielowątkowy serwer www jaki Python posiada standardowo w swych bibliotekach) Dla garniturowych to może być argument. W Pythonie (RoR pewnie też, bo ma przecież webricka) możesz napisać aplikację, któa będzie działać zarówno w internecie jak i bez internetu, na płytce CD - może to służyć jako przenośne demo dla potencjalnych klientów.
Po trzecie, PHP jest zaprojektowany koszmarnie, właściwie w tym nie widać żadnej spójności. Globalny śmietnik setek funkcji. Jeden są pogrupowane wg prefiksów, inne - nie. Parametry do funkcji są przekazywane w niespójny sposób. To znacznie spowalnia pisanie kodu. Ja widzę po sobie. Mimo tylu lat doświadczenia w pracy z PHP, wciąż muszę czasem zaglądać do manuala. Dla kontrastu, w Pythonie (który znam krócej) piszę praktycznie bez zaglądania do czegokolwiek. Można też dodać, że w PHP tragiczna jest implementacja unicode. Praktycznie trzeba używać biblioteki iconv, który niszczy stringi jak spotka znak który nie może przekonwertować (np. z cp1250 do latin2 dla znaków polskiego dolnego i górnego cudzysłowu, długie myślniki itp)
Po czwarte, z wielu powodów, m.in. tych, co wyżej wymieniono, RoR pozwala na znacznie szybsze tworzenie kodu. I to nie makaronowego kodu-syfu jaki większość programistów PHP tworzy, ale kodu który będzie krótszy i czytelniejszy, czyli tańszy w utrzymaniu. RoR jest dobrze napisanym frameworkiem typu MVC. Minimalizuje możliwe błędy projektowe od samego początku.
Ruby może i jest piękny (jak uważa DHH) ale Python jest szybszy i ma kilka cech, których Rubiemu wciąż brakuje (np. bytecode, doskonała implementacja Unicode, named parameters, docstringi, mniejszy bałagan z metodami itp). Pythona można się nauczyć także znacznie szybciej od Ruby, bo oparty jest na lepszym założeniu odnośnie minimalizacji metod i struktur (Tam gdzie Ruby dodaje kolejne aliasy do tych samych metod, Python stara się aby uzyskać ten sam cel, możliwie w jeden i tylko jeden, poprawny sposób).
TurboGears jest oparty na CherryPy i dziedziczy wszystkie jego wady implementacyjne i amatorskie podejście jego developerów (odwieczny problem poprawnego zaimplementowania sesji jest już przedmiotem szyderstw). Zdecydowanie nie jest wart stosowania do czegoś poważniejszego i nie jest raczej żadną konkurencją dla RoR.
Django wciąż nie ma wersji 1.0, trwają prace nad usuwaniem “magii” z kodu (co znaczy że API się zmieni), ale jest frameworkiem zdecydowanie nastawionym na budowanie portali. Django ma wbudowany mechanizm autoryzacji i i18n, oraz świetny panel admina. W RoR trzeba to sobie napisać (podobno ma być plugin z czymś podobnym, ale kiedy - nikt nie wie).
Jest jeszcze Pylons (oparty na solidnym i szybkim Myghty + Routes i skopiowanych helpeach Railsów) Jest bardzo elastyczny i szybki. W moich testach pobił PHP 5.1 i to przy bardzo prostej aplikacji, gdzie PHP zwykle jest najszybszy.
Jednak zaletą RoR jest kompletność i DRY. Żaden z innych frameworków aż tak daleko się nie posunął w zakresie unikania powtarzania kodu. RoR jest inowacyjny, wypasiony (w zakresie możliwości) i ciągle ucieka naśladowcom.
Odnośnie dotarcia do garniturowych to chyba najlepiej po prostu przekonać ich jakimś przykładem. Np. muszę pracować w PHP4, bo tak zadecydowano, ale już wygryzłem cały ich system aktualizacji danych między bazami. Mieli to napisane w jakiś kompletnie idiotyczny sposób. Nieważne, że mieli z tym kupę problemów, ciągle coś nie działało. Każda próba naprawy wlekła się całymi dniami, wymagała rekompilacji dll dla .NET, restartów, poprawek w php. Upierali się, aby to zostawić, bo “działało”. Ale do czasu. W końcu tak się w tym zamotali że funkcjonalność padła i nie wiadomo było kiedy to da się naprawić. Z oporami, ale zgodzili się na przepisanie systemu do Pythona. Po paru godzinach miałem działający prototyp - nie mogli uwierzyć. Po 3-4 dniach miałem kompletny system, który oni pisali miesiącami. Jeśli wcześniej nie zmienię firmy, to może doczekam się nawet dnia kompletnego wypieprzenia PHP.
Będę musiał zastanowić się nad Pylons. Brzmi bardzo ciekawie. Kłopot z Railsami jest taki, że nadal nie ma zbyt wielu programistów, którzy umieją w nich pisać. Ostatnio od firmy odszedł “programista”, który zostawił po sobie niedokończoną i do tego koszmarnie napisaną aplikację… Na pewno garniturowi boją się też o taką sytuację. Piszę duży kawałek aplikacji i nagle odchodzę, lub żądam chorych stawek za dokończenie - ciężko będzie znaleźć kogoś innego znającego railsy i dodatkowo trzeba doliczyć czas na wniknięcie w kod osoby niezapoznanej z aplikacją.
Najgorsze jest to, że firma nie jest duża i admin jest dość wysoko w “hierarchi” - o przestawienie się na php5 proszę już od jakiegoś czasu. Co dopiero o zainstalowanie Railsów…
Chyba będę musiał zrobić to, o czym wspominałeś powyżej: napisać działający protoyp w krótkim czasie i w taki sposób zaprezentować moc tych framework’ów.
A propo zalet - jak sobie radzą Railsy/Pylon z pracą na wielu bazach danych? Nigdy nie pisałem nic, co by tego wymagało, a mógłby to być dodatkowy argument za: w aplikacji o której pisałem na początku dane są zczytywane z 3 baz danych. 2 razy PostgreSQL i raz MSSQL.
I jak już rozmawiam z doświadczonymi ludźmi to powyciągam jeszcze kilka informacji ;-). Jak się przedstawia sprawa z frameworka’mi opartymi o php, które są niby wzorowane na Railsach? Na przykład Symfony, albo PHP on Trax?
Przepraszam, że tworzę na forum o Railsach dyskusję o sprawach około framework’owych, ale zauważyłem, że z reguły zwolennicy railsów sprawdzali też różne inne rozwiązania.
Pozdrawiam i dziękuję za odpowiedzi.
EDIT:
I jeszcze jedno pytanie na koniec - wiem, że w Railsach dodano ostatnio metody łatwego pisania stron z użyciem ajax’a, tak żeby były funkcjonalne nawet dla przeglądarek, które nie są kompatybilne. Ostatnio patrzyłem na statystyki serwera i całkiem dużo osób używa jeszcze internet explodera 5.0, a prototype działa zdaje się od 5.5, scriptaculous od 6.0. Co z Pylons?
Jak sobie radzicie z kompatybilnością? Zakładacie, że stare przeglądarki to bardzo mały procent, czy próbujecie dostosować jak najbardziej aplikację?
To nie jest problem Rails - to jest problem każdego systemu w każdym języku. Zarówno w PHP jak i Railsach czy Pythonie można napisać “potworka”.
Od kiedy admin jest architektem ? Nie wiem jak mam rozumieć hierarchję, ale jeżeli jest jednym z właścicieli firmy (ew. udziałowcem) to raczej powinno mu zależeć na zwiększeniu efektywności.
Railsy bez problemowo - no może bez przesady, ale całkiem nieźle.
Moim zdaniem przewaga RoR nad PHP to implementacja obiektowości. PHP jest raczej obiektawe niż obiektowe. Dodatkowo mam alergie na $this->ble();
Uwierz mi, to jest naprawdę najmniejszy problem. Railsy są łatwe do nauki. Są dostępne doskonałe materiały, filmy, książki. Może nie powinienem to pisać, ale i tak każdy łatwo może sprawdzić, że w sieci emule są dostępne pliki PDF z książkami “Agile Web Development in Rails” oraz “Programing in Ruby. 2nd Edition”. Ja sam wpierw ściągnąłem, obejrzałem i kupiłem, bo to są naprawde b. dobre książki.
To nie jest prawda, że łatwo znaleźć programistów PHP. Najłatwiej znaleźć łamagi, co myślę, że znają php bo poczytali trochę na jego temat i zrobili parę stronek. Dobrych programistów PHP nie znajdziesz łatwo, bo ci dobrzy korzystają z frameworków i posiadają wiedzę znacznie wykraczającą poza mieszanie php z html. Jak żyję, widziałem tylko parę osób które umiały posługiwać się dobrze PHP.
No właśnie. Problem z PHP jest taki, że b. łatwo o napisanie koszmarnego kodu. Railsy zmuszają cię do tworzenia kodu eleganckiego i czytelnego. Rails to framework. Narzuca ci dobre standardy projektowania aplikacji. PHP daje wolną amerykankę i zwykle w miarę wzrostu złożoności, powstaje coraz większy syf.
Czas na wniknęcie i opanowanie zasyfionego kodu PHP wcale nie jest mały. Railsy dzięki elegancji Rubiego ułatwiają pisanie kodu znacznie krótszego i czytelniejszego od PHP.
Myślę, że to żaden problem. Najnowsza książką o Railsach “Rails Recipies” cały rozdział poświęciła korzystaniu z wielu baz.
Najbardziej rozbudowany to Symfony. Trochę się mu przyglądałem ale się zniechęciłem. Railsy są znacznie prostsze do opanowania. PHP jest zbyt mało dynamiczny i mało obiektowy aby udało się w nim skopiować funkcjonalność RoR. Trzeba się znacznie więcej naklepać, więcej namęczyć, więcej czasu stracić, aby to ujarzmić.
Fakty są takie, że Python i Ruby bije PHP na głowę czytelnością kodu. Kto raz pozna Pythona czy Ruby, to będzie mu bardzo trudno wrócić do katowania się w PHP. Zaś Railsy czynią tak doskonały użytek z dynamiki Rubiego, że uzyskano efekt prostoty nieosiągalny nawet dla Pythona.
Apropos Rubiego, zajrzyj na tą stronkę: http://tryruby.hobix.com. 15 minutowe, interaktywne wprowadzenie do języka
Można, ale nie tak samo łatwo. PHP z racji swojego bałaganiarstwa projektowego, znacznie bardziej ułatwia stworzenie koszmarnego kodu. Koszmarki typu spaghetti code to coś bardzo często spotykanego w kręgach pehapowców. Rails przynajmniej wymusza trzymanie się jakichś rozsądnych ram projektowych. Bariera wejścia w Rails jest też znacznie niższa niż w inny framework (nawet Pylons).
Dobra… od jutra zaczynam batalię o wprowadzenie railsów.
Dziękuję za wszystkie rady, na pewno przydadzą się przy rozmowach. Na początek można postawić railsy tylko na serwerze testowym - jak już zobaczą o co biega prawdopodobnie zgodzą się na całkowite przejście.
Potwierdzam :)Miałem kryzys - programowałem w PHP przez 7 lat, ale naszczęście kryzys już minął i na PHP patrzec nie moge. Doszło nawet do tego że bardzo mocno rozważam przepisanie pewnych aplikacji z PHP na RoR (out-of-profit).
Zgadzam sie z ruthrsc i jzabiello, ale dodam tez troche od siebie.
Nie bede ganil php bo juz sami znawcy zagadnienia sie tym zajeli
Co do szybkosci ruby rzeczywiscie nie jest najlepiej. Ale to dlatego, ze nie ma on jeszcze vm-a jak java czy python. Ruby wraz z wersja 2 dostanie yarv-a (http://www.atdot.net/yarv/) i kto wie czy nie wyprzedzi pythona, kt. vm jest juz wiekowy. Performance tez nie jest najistotniejsze bo bottlenecks mozna zalatwiac uciekajac do kodu natywnego lub rozwazan posrednich. Np. na wiki rails do generowania pdf-ow jedna proponowanych z opcji jest JasperReports.
Z tego co widzialem w Symphony to ich ORM uzywa xmla do mappingow (ale juz do konfiguracji zrodla danych yamla - co za niekonsekwencja!). Przypomina to zywcem hibernate, ale … nikt juz tak nie pisze, a nawet przedtem uzywalo sie do generowania hbm.xml xdocleta. Obecnie panuje tendencja robic meta-programming poprzez annotations i uzywac xmla tylko tam gdzie jest to konieczne (konfiguracja beanow w springu).
Skoro frameworki php kopuja rozwiazania z java anno domini 2003 a sam jezyk jest daleko niedoskonaly to nie spodziewalbym sie po nich zadnych rewelacji.
ActiveRecord nie ma problemu z praca na wielu baz danych, ale …
Nie ma mozliwosci rozpiecia transakcji nad wiecej niz jedna baza (2PC). Mozna zasymulowac poprzez transakcje zagniezdzone ale to niedoskonale rozwiazanie.
Jak sie okazuje (http://blog.exis.com/colin/archives/2006/02/17/jta-does-not-equal-automatic-support-of-two-phase-commit) w java world tez jest to wyzwaniem i trzeba uciekac na server aplikacji implementujacy pelny XA. Co ciekawe autor artykulu wspomina rowniez o wlasciwosci Springa pozwalajaca synchronizowac transakcje z operacjami na nietransakcyjnych danych (np. LDAP)
a co uzytkownicy Rails znaja za callbackow typu before/after_update.
Oprocz Rails istnieje rowniez taki framework jak Nitro.
Na koniec dla garniturowych:
Jak sie okazuje (na forum sa linki do artow) Rails jest niezla alternatywa nie tylko dla php ale rowniez “heavy-industry” java.
Maintainability, extendibility, robustness maja czesto wyzszy priorytet niz performance zwlaszcza dla aplikacji dobrze sie skalujacej.
Dobrych programistow php (OO, best-practises) jest prawdopodobnie mniej niz tych od pythona, a z pythona do ruby droga niedaleka.
Czas wykonania aplikacji jest ok. 2x krotszy w Rails niz w Java (znajac i wykorzystujac nowoczesne frameworki jak Spring, Hibernate, Tapestry, Rife itd. bo uzywajac samych servlet/jsp api, Struts i ejb2.1 to boje sie nawet spekulowac)
Skoro przedmowcy potwierdzaja (co podejrzewalem), ze w Rails pisze sie szybciej niz w Php to w rezultacie mozemy otrzymac “well-structured” aplikacje w czasie, w ktorym sklecic mozna jedynie phpowego badziewia.
Specjalizacja w php zaweza pole dzialania tylko do aplikacji webowych podczas gdy w pythonie czy ruby mozna z powodzeniem pisac aplikacje desktopowe (toolkitow gui do wyboru, do koloru). Oczywiscie nie mowie tu o grach OpenGL
PS. Byc moze sam bede musial stoczyc batalie o Rails vs. Java wkrotce
Python nie posiada pełnej JVM i nie wiadomo czy i kiedy to napiszą. Z tego, co widze, to generowany bytecode dotyczy praktycznie tylko ładowanych modułów i skraca czas ich ponownego ładowania. Ale nie daje to jakiegoś znaczącego przyrostu wydajności. Mimo to Python jest i tak szybszy od Rubiego, i to jest odczuwalne. Jeszcze większy przyrost wydajności Pythona jest na JVM Javy (Jython) i CLR .NET’u (IronPython). Skrypty odpalane tam są znacznie szybsze od standardowego CPythona nawet z akceleratorem Psyco. Po prostu JVM i CLR są lepiej zoptymalizowane pod kątem wydajności.
Byc moze projektanci pythona nie chcieli pelnego vma ze wzgledu na startup time i memory footprint co moze nie obecnie ale bylo utrapieniem w javie i przyczynilo sie do powstania roznych legend. Albo problem lezal w wielowatkowosci i global interpreter lock pythona?
A to jest dla mnie nowosc! Chyba cos w zyciu przeoczylem Jak widze w profilerze ile klas sie laduje dla zwyklego okna to sie dziwie, ze cos takiego jak netbeans i eclipse w ogole dziala. A tu jeszcze dodatkowa warswa abstrakcji w postaci jythona. Musze pogooglowac!
Gleboko wierze w to, ze Railsy zyskaja taka popularnosc jak PHP, J2EE… ASP, ze przyszloscia web-development sa frameworki takie jak Rails czy Django i to jest nieuchronne tak jak dominacja jezykow OOP wysokiego poziomu abstrakcji.
Gdy powstanie kilka “spektakularnych” aplikacji enterprise’owych popyt zacznie gwaltownie rosnac ale do prawdziwego bumu jeszcze chwila.
Wierze rowniez w to, ze pionierzy zawsze wychodza na tym najlepiej.
Na szczescie jestem w komfortowej sytuacji, w ktorej przy doborze architektur mam wolna reke i nie musialem forsowac Railsow ale dodam, ze demonstracja kilku przykladow wzbudzila duzy entuzjazm przelozonych.
odświeżam temat bo sam znalazłem się w podobnej sytuacji jak niektórzy opisują, robię od paru dobrych lat w PHPie, odrobinkę Java, próbuję przeforsować jakieś nowe serwisy w pracy na bazie Railsów bo rzygam juz PHPem, ale napotykam na pytania typu:
czemu nie w PHP skoro to każdy zna, mają się wszyscy uczyć od nowa ?
skoro framework co czemu nie Zend ?
czytałem na internecie ze Twitter zrezygnował z Railsów, wiec coś z nimi pewnie jest nie tak ! (tego że zrezygnował na backendzie a do front-endu dalej stosują z powodzeniem Railsy to już nikt nie doczytuje, moim zdaniem Twitter niepotrzebnie narobił syfu Railsom, jakoś nikt nie oznajmia wszem i wobec gdy przechodzi z PHP na Railsy, o Twitterze huczało na necie, były głosy że obwiniają Railsy za swoje własne błędy)
w Railsach to można fajnie zrobić to do czego zostały stworzone a coś bardziej złożonego to już trudniej (?!?)
słyszałem że Railsy są wolne (to chyba najgorsza opinia przylepiona do Railsów i powtarzana bezmyślnie)
Jak byście odpowiedzieli na takie pytania ? Kto zna jakieś linki najlepiej po angielsku, które można pokazać menagerom, jakieś fajne wykresy itp bajery które mogą przeforsować Railsy ?
Moim zdaniem problemem jest to że PHP jest poprostu tanie, ludzi w tym robiących są tysiące i łatwo i tanio można kogoś zastąpić, więc decydują koszta a nie który język jest lepszy. W UK gdzie obecnie pracuje płace Railsowców zaczynają się tam gdzie prace PHPowców kończą.
Też już słyszałem wszystkie te argumenty i gotuję się za każdym razem, kiedy słyszę, że “Rails się nie skaluje bo Twitter…”.
Najlepszym argumentem wg mnie jest prototyp aplikacji, który w Rails możesz zrobić na jutro (tylko nie mów, że zrobisz na jutro - powiedz że będzie do końca tygodnia, a potem przynieś na jutro).
Zawsze Twierdziłem, że ludzie z Twittera to straszne lamy choć wielu z tego forum nie zgodziłoby się ze mną (no bo serwis duży i w ogóle etc.) choć sam namiętnie z Twittera korzystam.
Najpierw Twitter zaczął obwiniać Rails, że nie może się łączyć z wieloma bazami. Duże zamieszanie, ojej, Ruby nie może łączyć się wieloma bazami, co za porażka. I co ? I Dr. Nic napisał w 15 minut rozszerzenie umożliwiające łączenie się z wieloma bazami. Dużo zamieszania o coś co można samemu napisać w 15 minut ?
Później było obwinianie Ruby za to że się nie skaluje do Message Queues, choć Ruby nie został do tego stworzony i istnieją lepsze rozwiązania do MQ to blame trwał dobry rok albo i dwa.
Później komuś udało się zalogować jako Obama wykorzystując dziurę w pluginie do autentykacji którą napisali ludzie z Twittera. Od razu Techcrunch podłapał i wielka wrzawa jak to Rails jest insecure (chociaż to nie miało nic wspólnego z kodem Rails tylko z kodem ludzi z Twittera).
Gwoździem do trumny ludzi z Twittera jako technologicznego autorytetu było jak niedawno okazało się, że pracownicy Twittera zabezpieczają ważne dokumenty zawierające np. dane dotyczące rozwoju firmy hasłem “password”. Dokumenty wydostały się na zewnątrz, TC to podłapał i powstała kolejna wrzawa.
Jeśli ktoś chce obwiniać Ruby/Rails za błędy Twittera to proszę bardzo ale dla mnie poleganie na opinii ludzi, którzy zabezpieczają swoje ważne dokumenty hasłem “password” to epic fail
Artur79: z takimi argumentami ze strony twoich pracodawców widzę, że każdy problem, błąd z serwisem napisanym w Railsach będzie przez to, że to są Railsy. Najlepiej poświęcić parę tygodni na naukę Rubiego i Railsów i znaleść pracę w innej firmie Railsowców naprawdę brakuje, więc nie będzie z tym problemu.
EDIT:
Ewentualnie możesz pokazać, jak fajnie się pracuje z Cucumberem, choć nie wiem, czy zrozumieją potęgę tego narzędzia. Spróbuj znaleść artykuły o testowaniu i oszczędnościach dzięki temu - może to ich przekona.
Przeportowanie ogóra na PHP jest tylko kwestią czasu. Co prawda ekosystem PHP jest bardzo upośledzony jeśli chodzi o narzędzia do testowania – co wynika z upośledzenia ogółu programistów jeśli chodzi o (nie)pisanie testów – ale skoro Aslak zrobił Cuke4Duke dla Javy (z fajnym DSLem w groovy dla chętnych), to port do PHP nie jest teraz wyzwaniem. Więc Cucumber raczej nie będzie killer feature’em railsów.
Tak jak Sławosz pisze – możesz być samodzielnym krzyżowcem i szukać powodów (faktycznie mocne jest napisanie prototypu przez jeden dzień) albo znaleźć pracę w firmie, która railsy już doceniła i nie trzeba tam walić głową w mur
A to powiem z innej strony, żaden manago się nie zgodzi na wejście w coś, do czego nie ma na rynku ludzi. Firma ma tylko jedno zadanie: zarabianie pieniędzy, jakiekolwiek inne działania jak np: tworzenie super zajebistego kodu, używanie super zajebistych narzędzi, dawanie pracownikom super zdrowej kawy itd są nieważne. Liczy się tylko kasa. Jeśli mam pracownika, który zna rubiego, ale wiem, że on odejdzie/zachoruje/umrze i na jego miejsce nie znajdę nikogo innego, to ruby się dla firmy nie liczy. Najłatwiej znaleźć ludzi do php i javy. Oczywiście znalezienie dobrego człowieka do php graniczy z cudem, ale to jest jak ze wszystkim, ogólnie znalezienie dobrych programistów jest trudne.
Myślę, że jak będzie więcej programistów Rubiego czy Railsów, to sytuacja w firmach się zmieni.
No i oczywiście: jak coś się nie podoba, to zawsze możesz zmienić pracę na taką, w której będzie używany Ruby.
A co do mitu, że brakuje railsowców… ostatnio szukałem roboty, nie znam railsów jakoś baaardzo dobrze, tylko jakieś wprawki sobie dla siebie pisałem (czyt.: uczyłem się kilka miesięcy)… i dlatego nikt nie chciał ze mną rozmawiać, bo szukają railsowych wymiataczy, więc żadne kilka tygodni na naukę nie wystarczy. A nawet jak szukają kogoś do przyuczenia, to za taką kasę, że nawet mi się nie opłaca odpowiadać na ogłoszenie.
- o przestawienie się na php5 proszę już od jakiegoś czasu. Co dopiero o zainstalowanie Railsów…