W ogóle pluginy/gemy do autentykacji jako argument za zasadnością NIH i napisania czegoś in-house, jezujezu. Świstak, weź lepiej dobieraj kontrprzykłady, jeśli nie chcesz żeby wypowiedź była traktowana jako trolerska 
Schodzimy z tematu chyba trochę. Co do bibliotek to jest moje subiektywne odczucie będące tylko jednym z argumentów. W dodatku przypadki przeciwne (osoby sprawdzające biblioteki, rezygnacja z ficzera itd.) są niestety bardziej wyjątkami niż regułą.
Co do bibliotek odnośnie autorayzacji to tez był tylko przykład, niestety nie mogę się zgodzić że były dobre czy obtestowane (przynajmniej nie wszystkie), w dodatku jak były takie dobre i obtestowane i awesome to czemu powstają nowe? 
PS. Biblioteki do autentykacji są jak dla mnie świetnym przykąłdem ze wzgledu wałaśnie na mnogość i popularnosc właśnie. Oraz fakt że nic rewolucyjnego tu wymyślić nie można (z wyjątkiem oAuth) a mimo to powstają nowe i nowe.
Dodatkowo świetnie pokazują że wiele osób zainstaluje bibliotekę na wiarę (bo teraz sie autentykację Devisem robi), nie czytając kodu, w dodatku w miejscu tak krytycznym dla bezpieczeństwa jak autentykacja. Może szybka ankieta kto przeczytał cały kod devise? A kto używał w projekcie?
A kod źródłowy Rubiego w całości czytałeś? A code review zrobiłeś? A testy przejrzałeś? A używasz? …
Akurat jeżeli chodzi o Devise, to jeżeli biblioteki używa 90% społeczności i stoi za tym ktoś jaki jak Jose Valim, to (przynajmniej ja mogę) można częściowo “na wiarę” przyjąć, że nie jest to jakiś piecie of shit 
Nie wszystkich bibliotek to się oczywiście tyczy, ale nie pytałeś o wszystkie a o Devise
to lepiej żeby ktoś się “wyżył” programistycznie i napisał kolejną pierdzącą appke na iPhone’a
No straszna ta mnogość: aż trzy w ciągu ostatnich 5 lat, z bardzo wyraźnym podziałem na lata “rządzenia” (acts_as_authenticated/restful_auth zastąpiony przez authlogic zastąpiony przez devise). Blogger please.
O, to samo mówili javowcy i pehapowcy w okolicach 2004, na temat frameworków webowych.
Ja. Wystarczający code review (git clone, rake test*, poczytanie kilku klas) zajmuje kilkudziesięciokrotnie mniej czasu niż napisanie własnego rozwiązania from scratch na podobnym poziomie.
Jedynym projektem, któremu tego nie zrobiłem, jest Mongoid: zaufałem Durranowi, oraz skoro wkłada dane do bazy (mongo console ftw) takie jakie chcę i zwraca takie jakie chcę, to jest dla mnie bardziej niż wystarczający zbiór warunków dla O(R|D)Ma.
W ogóle jeśli biblioteka nie wystawia publicznie żadnych punktów (wektorów ataku), to nie rozumiem upierania się przy dokładnym code review. Wtedy może być dla mnie równie dobrze po prostu blackboxem, bo interesuje mnie wyłącznie co dostanę na wyjściu po nakarmieniu odpowiednim wejściem, oraz jak bardzo jest to zgodne z moimi oczekiwaniami.
- – z dwóch pierwszych kroków potrafi dziś wyręczyć travis-ci, można się szybko i łatwo zorientować w ilości testów w projekcie
A OAuth nie jest standardem autentykacji, w ogóle z autentykacją ma niewiele wspólnego. Świstak, proszę Cię ponownie, jeśli mam traktować poważnie
I co się stało, zminimalizowała ?
Co do ubogich narzędzi - to fakt, ale można nad tym pracować (zamiast nad wymyślaniem kolejnej biblioteki do autoryzacji). Przy okazji polecam obejrzeć prezentację o Nikicie
Punkt widzenia zależy od punktu siedzenia. Obecnie jesteśmy w momencie kiedy jeszcze nie pękła bańka 8.1 i 3.1 w Polsce oraz bombastycznych wycen startupów z USA - czyli jest masę kasy na rynku która wędruje m.in do programistów. Można dyskutować o psuciu rynku itd. itp. ale po co. 99% tych projektów padnie bo nie ma żadnego podłoża biznesowego - za to zostanie dobrze wyedukowana kadra która w końcu będzie musiała zejść z wymagań finansowych - tak było np. w świecie pehapa w 2008.
Jeśli jesteś polską małą firemką, mieszczącą się w dużym mieście (zwłaszcza w wawie) i nie masz technicznego wspólnika to tak jak napisał @filiptepper railsy są koszmarem do utrzymania. Inwestora zupełnie nie interesuje czy coś ma testy czy nie, ba czy nawet działa - ma generować przychody, jak największe przy jak najniższych kosztach, więc każdę 1-2tys./mc dodatkowych kosztów się liczy. Jeśli da się taniej to czemu nie, po co palić kesz - można wydać na marketing żeby zdobyć więcej klientów. Pewnie każdy zna wykop - kiedy zmienił się właściciel (z programisty na biz-guya) od razu przepisali na php - czemu? Bo wyszło taniej. Jeśli ktoś twierdzi że polscy inwestorzy dają za mało kasy - to mamy wolny rynek, można poszukać za Odrą albo w innych krajach.
Problemem są wyśrubowane wymagania finansowe pracowników którzy są święcie przekonani o swojej zajebistości Kilka typów których napotkałem na rekrutacji:
- Gość z czołowego polskiego rails software house’u (pewnie każdy z tego forum kojarzy firmę), który chciał pracować zdalnie, zarabiać 40zł netto/h a potrafił jedynie jak to sam określił “pisać kontrolery”, nie miał pojęcia o bazach danych, nosql, keszowaniu, js, css itd. Ponoć pracował jako senior developer. Co śmieszniejsze w ogłoszeniu były widełki które go wykluczały, ale takich zgłoszeń od “marzycieli” miałem masę.
- Drugi typ to “zrobiłem na studiach na zaliczenie blog w railsach i chciałbym 3tys netto bo potrzebuje na utrzymanie”. A ja potrzebuję…
- Kolejny typ zgłoszeń - “chętnie się przeniosę z języka X na ruby ale muszę zarabiać tyle ile w obecnej pracy na stanowisku seniora”
- Jeszcze lepsi są “ja to za bardzo nie lubię programować ale kasa w railsach jest najlepsza” - ale plus za szczerość!
Tak przynajmniej było rok temu. Oczywiście nie wszyscy tacy są, ale tezy że w środowisku railsowców wszyscy są już super programistami i że to wcale nie tak jak u tych brudnych pehapowców są wyssane z palca.
Odnośnie długu technologicznego itd - whatever, w startupach liczy się się aby dostarczyć jak najszybciej i rosnąć jeszcze szybciej, jak serwery nie wyrabiają to tylko dobry znak - kasa się znajdzie na nowe
Wracając do oryginalnego pytania leehookera: Warto być dobrym programistą, bo zawsze ma się wtedy pracę. Jak nie w Rubym to w Pythonie, jak nie w firmie na etat, to zdalnie w rozliczeniu za godziny, a jeśli nawet już też i to nie, to można sobie zawsze dorabiać na stronach crowdsourcingowych. Język wydaje mi się tutaj niezbyt związany z tematem. No chyba, że się zawsze chce być średnim, faktycznie wtedy warto podążać za językiem, w którym ma się największe szanse zatrudnienia.
Podsumujmy wypowiedzi z gatunku “Troll up”:
- Jest nam (programistom RoR) źle, bo dużo zarabiamy.
- Jest nam źle, bo nasze środowisko do pracy (infrastruktura + ekosystem) nad aplikacją można łatwo i szybko zainstalować i skonfigurować.
- Jest nam źle, bo do większości powtarzalnych zadań można wykorzystać dobre, wolne (as freedom) i gotowe rozwiązania.
Jakie wartości stały za Ruby i Ruby on Rails?
- time to market - chcę mieć możliwość szybko zaprezentować aplikację w maksymalnie akceptowalnej formie - z tego wzięła się znacząca przewaga wydajności pracy railsowca nad phpowcem (czyli: zapewniam taką samą/podobną wartość w krótszym czasie -> mogę domagać się wyższych zarobków)
2.a. least surprise - tworzymy środowisko w którym proste czynności są trywialne i maksymalnie intuicyjne
2.b. convention over configuration - wszelkie biblioteki i narzędzia są skonfigurowane domyślnie w najbardziej użyteczny sposób (np. devise i authlogic wymagają w klasach z użytkownikiem napisania aż jednej linii kodu dla wiekszości zwykłych aplikacji) - DRY - nie powtarzamy tego, co już ktoś (w szczególności: ja) wcześniej dobrze zrobił i unikamy pisania nadmiarowego kodu (a każda linia kodu to dodatkowy koszt utrzymania)
Według mnie, problemy z Rails i niechęć do niego zwykle nie mają podłoża technicznego, tylko biznesowe, ale uzasadniane są jako techniczne (bo taki język jest naturalnym środowiskiem funkcjonowania programistów)… i jeszcze “cierpimy” z tego, że nasz ekosystem miał lepszych marketing, niż równie dobre środowisko Pythonowe
P.S. Warto jeszcze rzucić okiem na to: http://rubyonrails.pl/forum/p16735-2010-02-10-13%3A04%3A23#p16735 i ogólnie dyskusję z tamtego wątku.
[quote=sbl]1. Jest nam (programistom RoR) źle, bo dużo zarabiamy.
2. Jest nam źle, bo nasze środowisko do pracy (infrastruktura + ekosystem) nad aplikacją można łatwo i szybko zainstalować i skonfigurować.
3. Jest nam źle, bo do większości powtarzalnych zadań można wykorzystać dobre, wolne (as freedom) i gotowe rozwiązania.[/quote]
Czytamy jakieś inne tematy, czy jak?
Świstak, Twoje wypowiedzi o kwestii jakości, utrzymania projektów, zależności dotyczą tak samo rubiego jak i innych dynamicznych/skryptowych języków (php, python, perl). Zagalopowałeś się trochę za bardzo sugerując, że ruby jest jakiś inny w tej kwestii.
Co do zarobków/kosztów pracodawcy to śmiem twierdzić, że się mylisz, tudzież, źle porównujesz. Myślę, że większość z Was zgodzi się z powszechnie panującą tezą, że w php programuje sporo początkujących programistów (niska bariera wejścia). Sprawia to, że średnia cena jaką trzeba zapłacić za programistę maleje). Nie zmienia to jednak faktu, że za dobrej klasy programistę php trzeba zapłacić tyle samo co za programistę rubiego. Przecież obaj programiści, poza klepaniem kodu w różnych technologiach przez 80% czasu robią to samo (struktura bazy, modelowania, analiza, projektowanie, optymalizacja kodu/sql/algorytmów, keszowanie i tak dalej).
@sbl: dla programistów super dla pracodawców (polskich) już troche gorzej.
@radarek: Odnośnie pierwszej części całkowicie się zgadzam, jedynym rozwiązaniem są języki typu smalltalk czy Ada.
Co do drugiej części wypowiedzi miałbyś rację ale 2 lata temu. Teraz niestety RoR osiągnął poziom php pod tym względem. Mnóstwo ludzi nie mających pojęcia o programowaniu ogląda screencasty i myśli “jakie to łatwe”. Niestety nie jest to łatwe.
Troszeczkę źle mnie zrozumiałeś, połowa mojej tezy jest że w tej chwili Ruby NIE jest inny w wielu kwestiach, C++0x, Python, PHP (w szczególności nowe frameworki MVC) gonią po piętach pod względem wydajności programowania, obsługi testów itd. Więc czemu przepłacać za Railsowca jeśli to samo można zrobić w PHP czy Pythonie za 30% taniej?
[quote=Tomash][quote=filiptepper]Ruby / Rails w Polsce powoli staje się utrzymaniowym koszmarem. Bardzo ciężko znaleźć dostępnych ludzi z doświadczeniem. Jeżeli się znajdą - są bardzo drodzy.
Co ciekawe (patrząc z perspektywy szukania inwestora) fakt, że napisaliśmy Durszlaka w Railsach jest dla nas obecnie obciążeniem, a nie atutem.[/quote]
Polski rynek biznesowy aplikacji webowych, także działających na nim “inwestorów” (wybacz cudzysłów, ale kilku poznałem i nie potrafię tego słowa w tym kontekście używać na serio), należy traktować bardziej jako kuriozum czy lokalne zaburzenie niż cokolwiek wskazującego globalny trend.
Trudno znaleźć kompetentnych rubiowców także w Niemczech czy USA. Co nie powstrzymuje startapów przed powstawaniem w Railsach, a inwestorów przed inwestowaniem w nie.[/quote]
Cokolwiek by o nich nie sądzić - to nasz rynek.
A można? U nas we wsi Pythonowcy cenowo nie odstają od Rubiowców.
Sam bym tego lepiej nie ujął.
I może nawet niekoniecznie pensja będzie jedynym wyznacznikiem. Kosztem / ceną jest też to, że przyzwoitego programistę PHP można znaleźć niemal od ręki. Ruby’ego nie. A czasem po prostu nie ma tygodni / miesięcy na czekanie.
Większość z was źle adresuje problem. Nasza branża (bez względu na język) to jedno z nielicznych miejsc gdzie nie ma i nie było recesji. Wystarczy spojrzeć na ilość ogłoszeń o prace gdziekolwiek, headhunterzy walą drzwiami i oknami. Brakuje rąk do pracy, ten sam problem jest wszędzie, Niemcy, UK, USA, Polska. To że w polsce łatwiej znaleść programistę PHP wynika prawdopodobnie tylko z tego że tych programistów jest więcej niż czegokolwiek innego.
PS. Ostatnio coraz więcej tu frustratów, chyba najwyższy czas przejść w standby mode 
To jest problem pracodawców. Przestali myśleć perspektywicznie w ogóle.
Każde zaproszenie na rozmowę ostatnio kończy się sakramentalnym “Kiedy może Pan wystartować bo chcieli byśmy jak najszybciej? - Za dwa miesiące? Niestety ni możemy tyle czekać, dziękujemy” albo “Czy mógłby Pan wystartować od razu”.
Najlepsze że w 2 przypadkach po 2 miesiącach dostałem zapytanie czy może nadal szukam bo pozycję która miała być zamknięta “na teraz” po dwóch miesiącach nadal była otwarta, po czym na odpowiedź “jasne akurat mi się kończy kontrakt więc za 2 miesiące mogę zacząć” dostawałem odpowiedź - oczywiście - że nie moga tyle czekać. Mało gościa śmiechem nie zabiłem.
Pracodawcy chcieli by świetnego programistę “od razu”, a ci najlepsi nie zmieniają pracy, a jak zmieniają często to mają jakąś inną poważną wadę typu niewyparzony język (tak to autoironia).
Jeśli przyzwoitość rozumiemy tak samo w obu ekosystemach (testy, git, skrypty do deploymentu, znajomość frameworków, projekty open-source itd.), to nie sądzę. Znajomy jest takim właśnie pehapowcem, chociaż umie też w django i railsach. Czemu robi w PHP? Ano bo ze swoim skillem i dobrymi nawykami jest większym (wartym większą pensję) rodzynkiem na rynku pracy pehapowców niż dwóch pozostałych technologii webowych.
Najlepsze startupy jakie znam rozwinęły skrzydła bez inwestorów. Nie jestem aż tak bezczelny żeby mówić Ci co powinieneś robić ze swoim startupem, zwłaszcza że masz w tym +inf więcej doświadczenia ode mnie, ale może warto rozważyć inne, bardziej bootstrapowalne opcje?
To część uroku Świstaka, ale nie każ mu przestawać – tego tematu chyba już nikt nie traktuje serio