Analiza SWOT (mocne strony, słabe strony, szanse, zagrożenia) dla Ruby on Rails. Pozycja obowiązkowa dla wszystkich osób pragnących zacząć w nim programować.
Kiedyś jak na zajęciach z ekonomii na pierwszym roku studiów trzeba było robić analizy SWOT dla wyimaginowanych firm, byłem przekonany, że był to jedyny raz kiedy coś takiego robię i że nigdy więcej na pewno tego nie będę potrzebował.
Minęło lat ileś i kiedy wpadł mi do głowy pomysł oceny Ruby on Rails, do głowy samoistnie nasunęła mi się analiza SWOT, jako dość dobrze nadające się narzędzie do pokazania różnych aspektów tego zjawiska.
Krótka definicja analizy SWOT (gdyby ktoś nie wiedział albo chciał sobie odświeżyć swoją wiedzę).
Strengths (Mocne strony)
Weaknesses (Słabe strony)
Opportunities (Szanse)
Threats (Zagrożenia)
Słownikowo (Wikipedia):
“Analiza SWOT – jedna z najpopularniejszych heurystycznych technik analitycznych, służąca do porządkowania informacji. Bywa stosowana we wszystkich obszarach planowania strategicznego jako uniwersalne narzędzie pierwszego etapu analizy strategicznej. Np w naukach ekonomicznych jest stosowana do analizy wewnętrznego i zewnętrznego środowiska danej organizacji, (np. przedsiębiorstwa), analizy danego projektu, rozwiązania biznesowego itp.”
Poniżej pokrótce moje opinie i obserwacje na temat słabych i mocnych stron RoR, ich szans i zagrożeń. Każdy z punktów (o ile nie jest ewidentny) rozwinę i wytłumaczę dlaczego tak uważam.
| Mocne strony 1. Proste i szybkie w budowaniu 2. Standardowa struktura aplikacji 3. Wbudowane testowanie 4. Społeczność 5. Dobry marketing (na świecie) |
Słabe strony 1. Problemy przy uruchamianiu na serwerze 2. Wolne działanie niektórych elementów frameworka 3. Dokumentacja 4. Słaby marketing (w Polsce) |
| Szanse 1. Rails 2.0 (dodatkowy buzz) 2. Potrzeba bardzo szybkiego tworzenia i szybkich zmian aplikacji 3. Rosnąca ilość dużych serwisów napisanych w Rails |
Zagrożenia 1. Nie zdobędzie masy krytycznej użytkowników 2. Nie zdobędzie masy krytycznej firm hostingowych 3. Wejście nowego gracza lub umocnienie się istniejącego 4. Brak (dobrych) programistów 5. Zaniedbanie / pominięcie Ruby (i/lub Rails) przez uczelnie |
Na początek plusy, które są dość powszechnie znane, bo są wałkowane na lewo i prawo jak część “buzzu”, który jest wytwarzany wokół Rails.
Prostota i szybkość developmentu. Struktura MVC (Model - View- Controller) narzuca pewne standarty, przez co nie trzeba się zbytnio zastanawiać gdzie co ma być, jakie to ma uzasadnienie i czy następna osoba będzie miała takie samo spojrzenie na to, gdzie muszą być poszczególne elementy aplikacji. Pomaga to w równoległym tworzeniu aplikacji przez kilku programistów albo w miarę bezproblemowym wdrożeniu się lub przejęciu projektu przez nowego programistę.
Wbudowane testy oraz niejako integralna i wpojona część filozofii Rails (TDD / BDD) ułatwia życie na dalszych etapach dużych projektów, kiedy to już nie da się wszystkiego przetestować ręcznie albo ogarnąć wszystkiego naraz.
Społeczność i dobry marketing. Nie widzę nic złego w tym, że ktoś na wiele możliwych sposobów promuje swoje rozwiązanie, o ile oczywiście to rozwiązanie jest dobre. Nie mam więc nic przeciwko temu, że chłopaki z 37 Signals (skąd wywodzi się Ruby on Rails) bardzo dobrze pokierowali społecznością railsową i umiejętnie wytworzyli szum, który pozwolił dość szybko i skutecznie wybić się ponad inne rozwiązania, zostać zauważonym i dzięki temu coraz szerzej stosowanym i akceptowanym.
Słabe strony
Nadal odpalanie serwisów (deployment) nie jest czynnością banalną, jak to jest chociażby w przypadku PHP (wrzucam na FTP’a i mi to działa). Istnieją narzędzia, które ten proces znacznie ułatwiają, jednak ciągle nie jest to tak bezproblemowe, jak mogłoby być “w idealnym świecie”.
Ostatnio pojawiły się dość burzliwe i intensywne dyskusje na ten temat, kwestia stała się dość powszechnie znana, a taki “PR” danej kwestii powinien moim zdaniem tylko zmobilizować społeczność railsową do znalezienia skutecznych rozwiązań.
Wolne działanie niektórych elementów frameworka. Przykładem może tu być chociażby named routes (nie jestem dobry w tłumaczeniu technologicznych pojęć na polski, więc nawet nie próbuję). W Rails 2.0 jest to jeden z kluczowych elementów, więc problem nie jest banalny. Są już jednak wprowadzane na to ulepszenia, które praktycznie niwelują ten problem, więc prawdopodobnie w najbliższej podwersji Rails powinno to działać dużo lepiej.
Nie będę zabierał teraz głosu w sprawie odwiecznych zarzutów typu “Rails doesn’t scale”, gdyż uważam, że dostatecznie dużo zostało na ten temat napisane. Nadmienię tylko, że jest to moim zdaniem problem w bardzo znacznej części rozdmuchany ponad to, jak jest rzeczywiście.
Dokumentacja. Standardowa dokumentacja API jest często niewystarczająca, ale chociażby projekt Noobkit ten problem stara się rozwiązać i to z dość dobrym skutkiem. Poza tym, jak wynika z punktów pozytywnych, społeczność jest dość pomocna. Grupy dyskusyjne czy kanały IRC zawsze okazywały mi nieocenioną pomoc kiedy niechcący skręciłem gdzieś w ślepą uliczkę i nie wiedziałem co zrobić dalej.
Sytuacja w Polsce zmienia się cały czas (i to dość szybko) na lepsze, aczkolwiek jeszcze widzę sporo miejsca na poprawę sytuacji, jeśli chodzi o polepszenie rozpoznawalności i akceptacji Ruby on Rails chociażby wśród większych firm w Polsce.
Szanse i zagrożenia
Serwisy internetowe są teraz tworzone w coraz większej ilości i coraz szybciej. Im bardziej cykl tworzenia serwisu jest zbliżony (czasowo) do cyklu wypieku świeżych bagietek, tym lepiej - z punktu widzenia twórców oczywiście.
Poprzednie narzędzia i metody powoli przestają dawać gwarancję tworzenia w takim tempie, mając cykl bardziej zbliżony do dojrzewającego wina, niż gorących bagietek.
Im większe więc będzie zapotrzebowanie na świeże pieczywo, tym większa szansa dla Ruby on Rails na rozwinięcie skrzydeł i uzyskanie dodatkowego uznania (na świecie i w Polsce).
Trzeba tylko zadbać, żeby była odpowiednia ilość dobrych piekarzy i poprawić system dystrybucji bułek (czyt. deployment).
Uczelnie też mogą mieć w tym swój spory udział. Wystarczy uznać, że Ruby (i Rails) są warte tego, żeby postawić na nich dość mocny akcent, a już samo to powinno dać w Polsce spore efekty. Pozostaje mieć nadzieję, że skostniałe (oby jak najmniej) struktury uczelniane jak najszybciej dojdą do takich samych wniosków.
No i ciągle trzeba dbać o to, żeby za kilka lat ludzie nie uznali, że wolą np. nie ciepłe bułeczki, a choćby fastfood. Na razie to nie grozi i maszyna marketingowa (wraz z produktem, który sam się broni) działa należycie, ale nie można tego elementu zaniedbać.
Wnioski
Podsumowując (bądź streszczając dla leniwych, którym nie chciało się czytać powyższych wywodów):
Jest dobrze, może być jeszcze lepiej.
Idealnie nie jest (bo nic nie jest idealnie), ale jest do czego dążyć.
I jest to wniosek dla Rails ogólnie, jak i dla RoR w Polsce.
Przedruk dokonany za zgodą autora
Źródło: Radek Sienkiewicz