Tomash ma wątpliwości wiec rozwinę temat:
Ruby on Rails sam w sobie zawiera 30 bibliotek jako zależności. Do tego cżesto w pierwszej kolejności instaluje się cancan-a devisea, i 3-4 inne standardowe biblioteki.
Problemem z którym najczęściej się spotykam w projektach Ruby on Rails są zależności. Ktoś kiedyś uznał że warto uniknąć NIH wrzucił w github.com kilka fraz i dostał bibliotekę która robiła to co potrzebował.
I ekstra, z tym jednym problemem, większość osób nie robi code-review bibliotek. Taka jest prawda taki jest fakt. Jestem pewien że są ludzie którzy tak robią, ale wiele ich nie ma. Nie wspominając że często porządny code review trwałby dłużej niż napisanie tego samemu, ale należy unikać NIH więc instaluje się bibliotekę.
Ćwiczenie: przejrzyj jakiś swój projekt większy, przejrzyj biblioteki i sprawdź ile z tych pluginów ma w ogóle testy? a ile z nich ma sensowne pokrycie?
Niestety najczęsciej co z oczu to z serca, skoro gemów nie widać, to nei ma znaczenia ile ich jest.
I teraz masz problem bo rok później musisz dodać funkcjonalność to albo kombinujesz z rozszerzeniem, albo forkujesz, albo wreszcie przepisujesz samemu. To jedna forma długu.
Druga forma długu istnieje w miejscach gdzie Railsy tracą swój szkielet. Cssy, javascripty itd. W pewnym momencie to zauważono i wersja 3.1 już poprawiła to bardzo mocno, ale te wszystkie projekty w rails 2.3 będą jeszcze straszyć latami.
I na sam koniec testy.
Teraz należy odróżnić dobrego programistę od złego programisty, oraz programistę z kręgosłupem od programisty bez, oraz programistę elokwentnego od standardowego.
Dobry, elokwentny programista z kręgosłupem powie: “Nie mogę zgodzić się na postulat żebyśmy odpuścili sobie testy. Rozumiem że deadline jest ciasny, ale z doświadczenia wiem że pisanie testów pozwoli nam nie tylko na dokończenie projektu przed deeadlinem, to jeszcze znacząco zmniejszy liczbę błędów w testach akceptacyjnych”
Głupi programista powie: “Nie potrzebuję testów, jestem przecież świetnym programistą, błędy zdarzają się innym”
Programista bez kręgosłupa powie: “Ok. Rozumiem że deadline jest blisko, myślę że możemy sobie odpuścić testy pod warunkiem że nadgonimy po releasie”
Programista nieelokwentny spróbuje powiedzieć to co elokwentny ale mu nie wyjdzie 
Tak więc teraz masz anegdotyczne szanse 1/6 że w ogóle testy będą pisane na bieżąco.
W pewnych warunkach na przykład przy instalcii bibliotek “ból” miał swój cel, miał zmusić programistę do zastanowienia się 2 razy czy na pewno potrzebuje tej biblioteki. Railsy + gemy + github zmniejszyły ból na tyle, że teraz na porzadku dziennym jest instalowanie kombajnów i dziesiątek bibliotek do robienia największych pierdół (a w jQuery to już w ogóle można znaleźć pluginy do robienia najmniejszej pierdoły, aż czekam kiedy się pojawi plugin do dodawania).
W konsekwencji Ruby on Rails akumuluje dług technologiczny na niespotykaną dotychczas skale ze względu właśnie na swoje zalety:
- niesamowicie dobre zarządzanie zależnościami.
- Wysoką integrację (z css i js jako przykładami).
- Bardzo wysokie tempo tworzenia oprogramowania
- Dynamiczną naturę.
Wszystko to jest niesamowicie przydatne gdy musisz wprowadzić aplikację na rynek, i cholernie problematyczne gdy musisz ją utrzymywać przez 5 lat.
