Od jakiegoś czasu staram się w miarę możliwości rozgryzać Ruby on Rails i chciałbym go wdrożyć w firmie, w której pracuję. Jestem w dziale, który zajmuje się głównie tworzeniem/modyfikowaniem aplikacji intranetowych w PHP dla jednego klienta (niektóre mają po 10 lat, co jest niezłym “pain in the ass”). Problem polega na tym, że piszę się wszystko od zera, nie testuje, słabo lub nie dokumentuje i ogólnie jest tragedia.
Rzecz w tym, że dostałem “prawie” zielone światło po krótkim wstępie o RoR na realizację najbliższej aplikacji, muszę tylko przygotować prezentację na temat korzyści wynikających z jego użytkowania. I teraz najważniejsze - prezentacja musi być taka, żeby przekonać nietechniczne szefostwo do używania tego (pomimo, że będzie też kilka jakichś programistów, ale pewnie z innych działów).
I tu prośba do Was, doświadczonych w RoR, o wskazanie Waszym zdaniem najistotniejszych punktów Ruby on Rails czyniących go doskonałym narzędziem do tworzenia aplikacji.
Ja sam mam niewielkie doświadczenie, pomyślałem więc o CoC, DRY, narzędziach do testowania (np. RSpec), możliwości użycia go z Apache (to jest istotne), działaniu ActiveRecord w przykładach, walidacjach. Pewnie wydaje się to trywialne, ale chodzi o pokazanie, co framework daje “out of the box” i na czym firma zyska, bo o to się rozchodzi.
Zacznę może od małego offtopica.
Przede wszystkim zastanów się czy wiesz co robisz. Z twojego postu pośrednio wynika, że traktujesz railsy jak ósmy cud świata i silver bullet rozwiązujący wszystkie problemy w twojej organizacji (“Problem polega na tym, że piszę się wszystko od zera, nie testuje, słabo lub nie dokumentuje i ogólnie jest tragedia.”). W każdym razie ja to tak odebrałem. Pamiętaj, że w railsach można pisać również zagmatwany kod, a testy również same się nie napiszą. Jeśli sam nie masz jeszcze doświadczenia nie będziesz nawet za bardzo miał możliwości stwierdzenia czy piszecie coś dobrze, czy nie. Przygotuj się na mnóstwo jojczenia nt jak to prosto można coś zrobić w php w jeden linijce (a tutaj jakieś modele, testy, konwencje, srencje). Ludzie,
szczególnie tacy, którzy piszą na odwal się, nie lubią zmian. Generalnie każda porażka może stać się powodem do obwiniania ciebie i frameworka który
próbujesz wprowadzić.
A teraz (jeśli wziąłeś to pod uwagę) przejdę do rzeczy
To co moim zdaniem jest mega fajne w railsach to konwencje. Otwierasz nowy, nieznany projekt i masz już jakieś ogólne pojęcie gdzie co znajdziesz.
Tutaj leżą modele i logika, tutaj kontrolery, tutaj widoki a tutaj javascripty. To robi się tak, a to tak. Ktoś napisał coś w ten sposób, a więc chodziło
mu o to i o to.
Railsy posiadają migracje. Piszesz, że w twojej firmie powstają aplikacje, których czas życia jest bardzo długi. Bardzo pomocną rzeczą w tym wypadku
są migracje bazy. Dzięki nim możesz zachować w miarę rozsądną historię zmian i operacji na bazie danych. Bez większego problemu możesz zmienić strukturę bazy.
railsy już same zadbają o to, żeby twoja baza testowa też była w odpowiedniej wersji, żeby wszystkie zmiany zostały zaaplikowane na produkcji itd.
Railsy używają activerecordu. Jeśli kiedyś dojdziesz do wniosku, że lepiej byłoby przenieść się z jednej bazy do drugiej - w wielu wypadkach jedyne co musisz zrobić
to zmienić po prostu sterownik w Gemfile i database.yml
To tak na szybko z rzeczy które mogą wydać się spoko ludziom nietechnicznym.
Polecam też wątek na stackoverflow (co prawda o django, ale adekwatny):
"Your boss should understand that it’s in his best interest to work in what the people he’ll be employing know best.
But, how can you tell that Django is really the best suit all things considered?
For example:
Are the servers in-house? do the sysadmins know how to maintain servers for Django?
Are the servers in a webhost, do you know how much does it cost to have a Django webhost versus a PHP one?
Are the rest of the team familiarized with Django/Python? If you are a one man team, what if your boss wants to make the team bigger, will he be able to? At what cost? PHP devs abound.
Given the PHP framework of choice, can you honestly give some criteria that will translate to dollars (or whatever your currency is) giving Django the advantage? Say, time to market, or some features that will be used and come for free in Django but not in the other alternative? Don’t forget that if you are a good programmer you can create good programs in any language.
This are just some things you have to consider before presenting with your boss with a “PHP sucks, let’s use Python instead” speech. I understand the feeling but it really might not make sense in the long run in certain cases. If, after all these things are answered (and some more), you can still present a good case for Django, then you should do so. Just don’t do what sounds to a business man like fanboy speech."
To co przewija się we wszystkich takich wątkach to również:
“Given a task, work on it and finish it with the current technologies/tools that everyone is using. In addition to that, work on the same task individually in the technology/tool you want to convince your boss to adopt. Then, when the day comes to show your boss your work, show him/her also your side project and explain them the benefits. Once they see both implementations, can compare them and really “feel” the benefits, they might be convinced more easily.”
Musisz się liczyć z tym, że jeżeli wszyscy w pracy mają doświadczenie w php i nagle będziesz musiał ich przestawić na railsy, to może powstać jeszcze gorszy kod niż w php Ruby pozwala na dużo więcej, ale możesz sobie też zrobić większą krzywdę.
Jeżeli uda Ci się przeforsować railsy, to warto poszukać jakiegoś “mentora”, tzn. jakiegoś doświadczonego programistę, którego firma wynajęłaby nawe na kilkanaście godzin miesięcznie, żeby wskazał drogę. Doświadczeni railsowcy nie są tani, ale myślę, że taka inwestycja się opłaci.
Co do samego pytania, to wszystko zależy od tego jakie masz szefostwo. Według mnie najważniejsze rzeczy to:
Wysoka kultura testowania (łatwiej się testuje, jest dużo fajnych narzędzi, dużo materiałów na ten temat) - pisanie kodu z testami zajmuje więcej czasu, ale w dłuższym okresie się “zwraca”.
Ruby jest językiem ogólnego zastosowania. Dla mnie to bardzo ważne, bo dzięki temu w ruby masz nie tylko aplikację, ale też narzędzia.
Ruby jest nastawiony na zadowolenie programisty
Bardzo duża liczba pluginów do railsów - do większości tasków coś znajdziesz (co też ma swoje minusy, czasami lepiej jest napisać własne rozwiązanie)
Potężne możliwości języka (metaprogramowanie), co sprawia, że wiele problemów jest dużo łatwiej rozwiązać
Genialne narzędzia do deploymentu (capistrano!)
Dla mnie to chyba są najważniejsze rzeczy, ale pewnie każdemu podobają się trochę inne apekty korzystania z railsów. Ważne żebyś mówił o tym w kontekście mniejszych kosztów utrzymania aplikacji w dłuższym okresie czasu, managerów z reguły nie obchodzi czy programista będzie szczęśliwy tylko ile będą musieli zapłacić za aplikację i jej utrzymanie
nie wiem czy dobrze piszę, jestem jeszcze raczej z ‘tych zielonych’ aale - skalowalność aplikacji napisanych w RoR? W przypadku rozbudowy / coraz większego ruchu / obciążenia dobrze napisana aplikacja nie wymaga wprowadzania zmian w kodzie, tylko zmiany w hostingu (np. jak na heroku - na dostęp do większej ilości zasobów serwera / komputera ?)
Ale wolałbym, żeby jakiś doświadczony railsowiec potwierdził moją teorię, bo jak już wspomniałem jestem z tych ‘green ones’ i bynajmniej nie chodzi mi tutaj o Yodę
Mała rada ode mnie: w miarę możliwości zatrudnij do developmentu/konsultacji doświadczonego programistę RoR. Naucz się też dobrze samego języka, polecam Ruby Koans http://rubykoans.com/. Jeśli będzie to Twoja pierwsza aplikacja w RoR, masz sporą szansę napisać ją bardzo źle.
Edit: dopiero zauważyłem że Piotr też napisał o wynajęciu kogoś kto udzieli Wam pomocy. Myślę że to jest bardzo ważne.
Nie będzie to moja pierwsza aplikacja, napisałem już co nieco. Znam RubyKoans - przerabiałem je.
Co do Waszych wątpliwości, że reszta powie “a fe”. Jest raptem dwóch pehapowców. Na pewno nie przebranżowimy się w 100% na Rails, to jest niemożliwe, to ma być tylko support (no i zysk dla mnie), tu nie chodzi o wymianę technologii. Dlatego zdecydowałem się napisać niedużą, wręcz małą aplikację na start. A może firma w międzyczasie zobaczy potencjał tego narzędzia i zatrudni jeszcze kogoś. Ok, zgadzam się, że nie musi być napisana ładnie, programuję już ponad 10 lat w różnych językach i wiem, jak to wygląda. To nie jest tak, że zobaczyłem Ruby on Rails, przejrzałem książkę, posikałem się w majty i chcę je wdrażać (chociaż może trochę tak mogło być ). Generalnie wiem w praktyce, że z kodu na kod jest coraz lepiej, jak komuś zależy i korzysta ze wszelkich dostępnych materiałów.
Opcja z wynajęciem kogoś odpada. Po prostu nie ma szans.
Właśnie, miałem o tym też napisać, ale późno było i wyleciało mi z głowy. W PHP też jest dużo frameworków, też można testować, dokumentację też pewnie uda się wygenerować
Pamiętam jak pracowałem kiedyś z klientem, któremu nie bardzo wychodził scrum. Mieliśmy iteracje 2 tygodniowe, ale z reguły w środku iteracji nagle zmieniała się wizja i klient chciał dorzucić kilka ticketów. Menadżer projektu wpadł na pomysł, żeby przejść na kanbana. Rozwiązałoby to wszystkie nasze problemy! O ticketach do zrobienia można decydować właściwie do ostatniej chwili, nie trzeba się bawić w iteracje, agile jak pińcset silnia. W praktyce wyglądało to tak, że przez pierwsze kilka dni było fajnie, aż klient zaczął zmieniać tickety, które były w trakcie implementacji. Agile miał być w końcu, nie?
Wiem, zdaję sobie z tego sprawę, ale ja w tą metodologie “wpadłem”, ja tego nie wymyśliłem.
Wierzcie mi, że próbowałem wszelkich sposobów, żeby poprawić sytuację. Kombinowałem tak i siak, bez większego skutku. Po prostu (może w akcie desperacji) przyszło mi do głowy to, żeby wprowadzić nowe, świeże narzędzie, gdzie uda się “przemycić” te techniki jako normalne w dzisiejszym świecie.
Narzędzia w PHP są. Pisaliśmy jeden projekt w Symfony, ale nastąpiło duże zniechęcenie, jak się okazało, że Propel ma w sumie słabe możliwości, jeśli chodzi o bardziej zaawansowane zapytania, a dokumentacja pozostawia wiele do życzenia.
Przy okazji, jeżeli daje mi się możliwość wykorzystania technologii, jaką chcę, to chcę wykorzystać ten moment.
Generalnie testy, refactoring i fanatyczny codereview powinny być na porządku dziennym, spróbuj kolegów przekonać. (no chyba, że tylko Tobie zależy a reszta olewa wtedy polecam dział: http://rubyonrails.pl/forum/f6-Praca---Projekty---Og�oszenia
Bardzo możliwe, że wraz z rozpoczęciem kodzenia w railsach zmieni się trochę kultura, więc jeżeli to ma być nowy mały projekt, to spróbuj, ale jak tylko zauważysz, że jest tak samo, ale w innej technologii to uciekaj gdzieś indziej.
Ruby pozwala na dużo więcej, ale możesz sobie też zrobić większą krzywdę.