Od kliku miesięcy rozwijam się w Railsach, ale ostatnio czuje chęć podłubać w czymś innym, ogarnięcia jakiejś nowej dla mnie technologii i przy okazji poszerzenia wachlarza własnych umiejętności.
Zastanawiam się jakie skille są dziś przydatne developerowi, który pracuje w Railsach? Interesuje mnie głównie web. Podstawy HTML/CSS mam dość solidne. Z Javascriptem za to na razie stoję kiepsko, a zawsze temat był dla mnie interesujący i myślę, żeby w tym kierunku się rozwinąć.
Co w ogóle dziś się używa w Ralisowych projektach? Chyba bardziej Ember niż Angular? Jakieś trendy wyczuwalne obecnie w JS? Jakie ew. inne skille są dużym plusem dla RoR Developera (poza oczywistymi, czyli znajomość baz danych, git itp.)?
1 Like
Z tego co mówisz, jest teraz idealny czas na naukę JS. To jest temat, który musisz ogarniać bardzo dobrze jako web developer. Z frameworków najbardziej na topie masz teraz do wyboru Angular, Ember, Backbone. Ja preferuję Backbone, ale to już jest kwestia preferencji co Ci najbardziej podpasuje (na szczycie stawki jeśli o trendy jest chyba teraz Angular).
2 Likes
Zdecydowanie javascript. Obecny trend jest taki że coraz więcej logiki wypada do przeglądarki, czyli aplikacji w javascripcie właśnie.
Najprostszy do rozpoczęcia jest Backbone, najpopularniejszy jest Angular, najbardziej “kompletnym” frameworkiem (coś jak Railsy ale dla aplikacji javascriptowych) jest Ember.
2 Likes
- A co to znaczy, że “coraz więcej logiki wypada do przeglądarki”?
- Czy JS to jest dodatek do aplikacji wykonanej w RoR, czy całkowicie jej zamiennik?
1 Like
Ad 1. Np budowanie skomplikowanych form uzytkownika. Zapewne @tomash mial na mysli logike zwiazana z widokami, bo jeszcze moze byc baardzo duzo logiki zwiazanej z backendem.
Ad 2. To zalezy od aplikacji
I co do frameworka, to polecam Angulara. Moze jest mniej ‘true’ ale ma swietna dokumentacje i bardzo duzo rozszerzen, warto sprawdzic jak wspolpracuje z firebasa albo ionic framework oparty na angularze.
1 Like
JS nie może zastąpić RoR, bo JS jest (z pewnymi wyjątkami, np. http://meteor.com) wykonywany tylko po stronie klienta (w przeglądarce). Ale fakt, że jest silny trend na to aby większość logiki aplikacji zrzucić na klienta. Tym samym RoR, Django czy podobny, “stary” framework, redukują się do serwowania i kontrolowania dostępu do danych.
Wydaje się, że twórcy Rails trochę przesypiają wagę lepszego wsparcia strony klienta, co może doprowadzić wkrótce do jego marginalizacji. Polecam http://www.naildrivin5.com/blog/2014/08/07/rails-degenerate-front-end-support.html
1 Like
Co do Angulara, to ja bym odradzał. Jest źle zaprojektowany do tego stopnia, że nowy Angular 2.0 musi być, i będzie, przepisany zupełnie OD ZERA. Angular 2.0 będzie połączeniem Angulara 1.x i Durandala 1.x (http://durandaljs.com), będzie zbudowany na modułach ES6 (użyty będzie transpiler), ma być lepszy router, bardziej przejrzyste API itp. itd. Pakowanie się więc w Angulara w kategoriach długofalowych się niezbyt opłaca. Tym bardziej, że Anguar 2.0 nie osiągnąl nawet wersji pre-alpha i upłynie pewnie rok albo i więcej zanim osiąganie jako taką dojrzalość.
Na tym korzysta tylko Ember. Od samego początku zaprojektowano go do skomplikowanych, złożonych aplikacji, i już teraz dzięki Ember-CLI ( http://www.ember-cli.com/ ) można używać modułów ES6.
Jeszcze jedna rzecz. Ember jest frameworkiem, a Angular toolkitem do budowania frameworków. To znaczy, że Ember nie jest aż tak totalnie elastyczny jak Angular, ale za to rozwiązuje masę problemów za developera (trochę jak to było założone przy tworzeniu Rails). Ember narzuca przemyślaną strukturę, konwencje i nazewnictwo plików i klas. Mówiąc krócej: framework ułatwia trzymanie się dobrych wzorców projektowych, a utrudnia ich łamanie. Zaś toolkit daje więcej wolności, dzięki temu łatwiej popełnić błąd w projekcie.
3 Likes
Bez przesady, ActiveModel::Serializers jest absolutnie rewelacyjny i tak naprawdę wszystkim czego potrzeba implementując w Railsach API. Jak pokazuje przykład nieudanych turbolinks i umiarkowanie udanych sprockets, najlepsze co mogą zrobić twórcy Rails to skupić się na robieniu dobrego frameworka server-side i zostawić client-side specjalistom.
Oraz tak bardzo +1 do tego co @hipertracker napisał o Angularze, trzeba w nim rozwiązywać mnóstwo problemów (już nie mówię o wymianie ng-routera na sensowniejszy komponent do routingu) które już dawno zostały rozwiązane w np. Emberze.
1 Like
ActiveModel to wciąż strona serwerowa. Do API może być (i przydać się może np.gem Faraday http://www.metacasts.tv/casts/faraday ) Jednakże, wsparcie strony klienta, tzn. zarządzanie assetsami, livereloadem czy, co ważniejsze, zależnościami między różnymi wersjami bibliotek JS jest w Rails po prostu słabe. Stąd wielu wspomaga się narzędziami opartymi na Node, npm, Bowerem http://bower.io/ lub (jeszcze lepiej) Broccoli, jak to jest używane w ember-cli. Sama koncepcja użycia frameworku JS automatycznie kastruje Rails do poziomu podawacza JSON’a. A to znaczy, że coraz bardziej Rails może po prostu okazać się overkill’em i tym samym traci znaczenie. Rails to aplikacja starego typu.
1 Like
Niekoniecznie. Po pierwsze ActiveRecord, ActiveSupport czy połowa Actionpacka (tj. bez templatek htmlowych) wciąż są bardzo przydatne, nawet jeśli w pakiecie “ogolonym” a’la rails-api. Po drugie ten “podawacz jsona” zazwyczaj jest spięty z jakimś panelem administracyjnym, a te w Railsach pisze się rewelacyjnie.
Nie bardzo widzę co miałoby Railsy zastąpić, nawet w kwestii pisania podawaczy jsona. Nie, Sinatra czy Padrino to nie są realne alternatywy dla aplikacji większych niż dziesięć ścieżek. Nie próbowałem jeszcze Lotusa.
3 Likes
Dzięki, ale zwroty słabo zrozumiałe dla osoby początkującej i nie-programisty. Czy chodzi o uruchamiania jakiś działań kodu w przeglądarce na pececie, a nie na serwerze? Czy to tak jak w PHP, gdzie część działania kodu strony internetowej jest wykonywana na serwerze? Tak zrozumiałem z wyjaśnienia @hipertracker.
Do angulara polecam: http://campus.codeschool.com/courses/shaping-up-with-angular-js/intro
Bardzo fajny kurs angulara
Tak, chodzi o przeglądarkę. Dla przeglądarki nie istnieje PHP ani Java. Istnieje tylko JavaScript, HTML i CSS (nie liczę pluginów jak Flash). Serwer tylko dostarcza dane w formacie JSON. A JavaScript w przeglądarce to konsumuje i buduje złożone UI. Robienie tego częściowo na serwerze, częściowo w przeglądarce, i to jeszcze za pomocą ręcznego bajzlu w jQuery to masochizm przy bardziej złożonym projekcie.
1 Like
Gotowy panel admina w Django też jest przydatny. I co z tego? Ja tu mówię o czymś bardziej złożonym, wymagającym więcej interakcji, animacji i dynamicznego przeładowywania powiązanych fragmentów DOM’u. Babranie się w budowanie HTML’a po stronie serwera to strata czasu i niepotrzebne utrudnianie sobie życia. Rails, jako podawacz JSON"a może być łatwo zastąpiony przez cokolwiek. Np. przez Node.js, który jest naturalnie non-blocking i nie trzeba używać dwóch różnych języków programowania (JS i tak trzeba używać, czy ktoś tego chce, czy nie)
BTW, coś dla minimalistów 
http://zappajs.github.io/zappajs/docs/crashcourse
1 Like
Uch. Napisałeś i utrzymywałeś coś nietrywialnego w nodejs? Najgorsza technologia server-side w jakiej robiłem, w kilku miejscach gorsza od PHP.
1 Like
Chyba żartujesz. Nikt nie pisze w czystym Node. Jeśli już to w Express, Sails czy innym frameworku http://designzum.com/2014/02/23/10-best-node-js-mvc-frameworks-for-javascript-developers/. Podany wyżej link do ZappaJS pokazuje jak prosto i wygodnie można budować sobie API. Prościej niż w Sinatrze (ZappaJS to wrapper w Coffescripcie na Express i Socket.io). Choć mnie osobiście najbardziej podoba się Meteor ( http:/meteor.com ), to krok wyżej od SPA, real-time web app.
1 Like
@meteor.com: wow!
Nie jestem na bieżąco, pisałem w Nodejs zanim Express miał sens i poza obrzydliwością języka (typowe quirki javascriptu plus callback hell) za dyskwalifikację uznałem wyjątki które powodowały wyjście procesu aplikacji.
Jest gdzieś jakaś duża i stabilna instalacja aplikacji napisanej w Nodejs? Najlepiej z opisaniem po roku maintenance’u jakie były zalety a jakie wady wybrania tej technologii?
No, trochę się zmieniło i zmienia. I to szybko. JavaScript dziś to potężny język. IMHO, potężniejszy od Ruby. Pisanie w nim jest przyjemne, ale trzeba wiedzieć czego używać.
JavaScript “dopalony” Lodashem ( http://lodash.com/ ), Sugar’em ( http://sugarjs.com/features ) czy Moment’em ( http://momentjs.com/ ) jest ładny i efektywny. Można się pozbyć zagnieżdżonych callbacków i dorzucić chain of promises za pomocą Q ( http://documentup.com/kriskowal/q/ ), owrapować wywolania ajaxa, asynchroniczne pub/subscribe do komunikacji między dowolnymi obiektami JS + cache dzięki Amplify http://amplifyjs.com/ podzielić kod na niezależne, z własną przestrzenią nazw, moduły ładowane z poziomu przeglądarki w stylu npm dla Node ( http://browserify.org/ ) lub asynchronicznie w stylu AMD ( http://requirejs.org/ ) itp., itd.
BTW, jest jeszcze jeden elegancki framework SPA, który zresztą nawet używamy produkcyjnie - Durandal http://durandaljs.com/
2 Likes
Co do dużych wdrożeń Node, to nie śledzę i mało mnie to interesuje. Technologia jest dosyć świeża, bardzo dużo się w niej dzieje. Ale z pewnością JavaScript to aktualnie najważniejszy język do aplikacji webowych. Ciekawą propozycję oferuje Passenger. Umożliwia nie tylko odpalanie i ładne skalowanie aplikacji w Ruby, Pythonie ale też w Node i Meteorze. Sam zarządza i restartuje procesy, wygodne rozwiązanie https://github.com/phusion/passenger/wiki/Phusion-Passenger:-Meteor-tutorial