Rails 2.0 - web aplikacje jeszcze bardziejsubiektywnie

aka. "A właśnie, że nie zreferuje ChangeLoga!"

Jarosław Rzeszótko, http://www.stifflog.com/

Słowa zajawki

- Rails 2 nie jest rewolucją z punktu widzenia technologii

- Rails 2 jest finalną opinią DHH i kolegów na temat tworzeniaaplikacji internetowych

- Lista zmian w Rails 2 jest jedynie kropką nad... no właśnie, nadczym?

- Większość zmian dotyczy "zasobów" i w komentarzach na tematwydania te własnie zmiany najczęściej sa pomijane lub kwitowaneziewnięciem...

- Najsłabiej rozumiany i najtrudniejszy aspekt Railsów, proszę więco skupienie

- A teraz czas na kontekst, który nieco zdominował tą prezentację...

Architektura aplikacji sieciowych

- Nowoczesne narzędzia programistyczne abstrahuja większośćszczegółów, która może zostać potraktowana jako "niskopoziomych"jak np. sposób komunikacji z użyciem protokołu HTTP

- Dla całej reszty świata nasza aplikacja jest widoczna jako zestawadresów URI wykorzystywalnych za pomocą protkołu HTTP

- Nie możemy więc świadomie tworzyć aplikacji WWW, ani rozpatrywaćnarzędzi służących do tworzenia takich aplikacji, bez zrozumieniafundamentalnych aspektów tejże globanej sieci

Czym jest World Wide Web?

- Wg. definicji Tim'a Bernersa Lee - współdzieloną przestrzeniąinformacyjną w której zarówno ludzie jak i maszyny mogą siękomunikować

- Prościej - siecią połączonych "dokumentów"

- Komunikacja maszyna<->maszyna staję się coraz ważniejsza

- Przykłady: mashupy, Yahoo Pipes, otwarte platformy, widgety,API, mikroformaty, semantyczna sieć, rozmaite programycrawlujące

- Moja opinia: prawdziwym krokiem naprzód w dziedzinie przepływuinformacji nie są ani nie będą serwisy społecznościowe, aumożliwienie komputerom głębszego rozumienia danych, które wolbrzymiej ilości udostepniamy

- "Komputer, przynieś śniadanie!"

Czym jest URI?

- Unikalny identyfikator każdego "bytu" w World Wide Web

- Spoiwem, który łączy poszczególne zasoby, w to, co "bywapowszechnie nazywane Internetem"

- Początkowo stosowany w odniesieniu dokumentów, został uogólnionyna szerszy zakres obiektów

- "Resource" w "Unique Resource Identifier"

"Zasobem może być wszystko co tylko posiada tożsamość. Prostymiprzykładami może być dokument elektroniczny, obrazek, serwis (np.'dzisiejszy raport pogodowy dla Los Angeles' albo kolekcja innychzasobów." - RFC2396

- Treść dokumentu może się zmienić, jego URI - nie powinien

Czym jest HTTP?

- Protokołem, opisującym w jaki sposób klient (przeglądarka, innyprogram komputerowy, itp.) komunikuje się z serwerem (komputerem iprogramem udostępniającym dane, które chcę pobrać klient)

- Dane te są hipertekstowe - zawierają odnośniki do innych danych,powiązanych z tymi, które właśnie pobraliśmy

- To połączenia pomiędzy danymi nadają sieci jej obecny kształt

- Protokół ten opisuje także w jaki sposób klienci mogą wydać żadanieutworzenia, modyfikacji lub usunięcia danych

- Nad sprawnym działaniem czuwa wielu niewidzalnych gościpośredniczących w połączeniu pomiędzy klientem a serwerem, którzysprawiają że WWW działa szybciej, bardziej niezawodnie, a przedewszystkim że dało się je wyskalować do tak wielkiej skali np.serwery proxy

Czym jest REST?

- Stylem architektonicznym - czyli zestawem wymagań, jakie musispełnić dana architektura aplikacji, by mogła zostać nazwanaRESTową

- Styl ten został ustalony i zastosowany do standardów HTTP 1.1 iURI, kiedy okazało się, że sieć nie spełnia nowych wymagańpowstałych na skutek popularyzacji WWW i coraz bardziejrozbudowanych aplikacji działających w tej sieci.

- Formalnej i jednocześnie jedynej sensownej definicji dostarczapraca doktorska Roy Fieldinga, twórcy RESTu, współautoraspecyfikacji HTTP 1.1 i URI

- ABC RESTu:

- Zasoby

- Identyfikatory zasobów

- Reprezentacje zasobów

Czym jest REST #2

Cechy RESTu w ogólności (niekoniecznie w odniesieniu do WWW):- Architektura klient-serwer- Bezstanowość- Zapamiętywanie zapytań (cache)- Jednolity interfejs- Wielowarstwowy system

Dla twórców aplikacji webowych:- Najważniejsze zaleta: zmusza do zastanowienia się nad projetkem

swojej aplikacji w świetle HTTP/URI- Minimalizujemy użycie stanu, każde żądanie powinno zawierać

wszystkie informacje potrzebne do jego zrealizowania- Obiekty, z którymi pracuje nasza aplikacja mapujemy na zasoby- Każdy zasób powinien posiadać unikalny adres URI- Zmiany stanu definiujemy za pomocą odpowiednich typów żadań HTTP

wysyłanych do odpowiednich adresów URI- Stan będacy rezultatem danego wywołania zwracamy z użyciem kodów

odpowiedzi i nagłówków HTTP- Podejście deklaratywne, zamiast imperatywnego

Esencja RESTu #1

"To co czyni HTTP znacząco różnym od mechanizmów zdalnegowywoływania procedur jest to, że żądania są kierowane do zasobówprzy użyciu uniwersalnego interfejsu ze standardową semantykąktóry może być interpretowany przez warstwy pośredniczące prawietak dobrze jak przez komputery bezpośrednio uczestniczące wdanym połączeniu. W rezultacie otrzymujemy aplikację, którapozwala na użycie warstw transformacji i pośrednictwa które sąniezależne od źródła informacji, co jest bardzo ważne wskalowalnym systemie informatycznym na skalę Internetu. Wodróżnieniu, mechanizmy zdalnego wywoływania poleceńzdefiniowane są w kontekście API poszczególnych języków, a niekomunikacji sieciowej."

Roy Fielding,"Architectural Styles and the Design of Network-based Software Architectures"

Esencja RESTu #2

- "Uniwersalny interfejs ze standardową semantyką"

- Jednolity sposób na pobieranie informacji zarówno przez ludzi,jak i przez maszyny/programy komputerowe

- Proste tworzenie elastycznych bibliotek

- Składnia zrozumiała dla programów komputerowych, działającychna skalę Internetu

- Alternatywy sprawiają, że składanie wywołań do różnychaplikacji nie ma żadnego wspólnego mianownika

Esencja RESTu #3

- "Warstwy transformacji i pośrednictwa które są niezależne od źródłainformacji"

- Największe zalety RESTu nie odnoszą się bezpośrednio do klientów

- Wiele zyskują elementy łączące - np. serwery proxy

- W alternatywnych podejściach funkcjonowanie tych elementów jestutrudnione lub uniemożliwione

- SOAP używa HTTP jako transportu by omijać firewalle...

- Dlaczego brak stanu może być pożądany?

- Ułatwione zadanie mają także np. wyszukiwarki

Rails - referencyjny framework dla RESTowych aplikacji?

- "Tak wyszło" - Rails nie był projektowany jako RESTowy framework

- Wraz z rozwojem każdego projektu zyskującego sporą popularnośćpojawia się pewien zestaw "najlepszych praktyk"

- Najważniejszą taką praktyką w Rails stał się sposób rozkładaniaaplikacji pomiędzy fundamentalne warstwy - model i kontroler.Rozrastające się projekty w Rails prowadzone przez dobrychprogramistów składały się najczęściej z:

- Bardzo "cienkich" kontrolerów, których wieksza częśćfunkcjonalności mapowała adresy url na odpowiednie akcje namodelach - odczytaj, utwórz, skasuj, zmodyfikuj, orazodpowiednio wybierające widok

- "Tłuste" modele, zawierające CAŁĄ logikę biznesową

- Na wiekszość modeli przypadały osobne kontrolery

Rails - referencyjny framework dla RESTowych aplikacji #2

- To wynika z MVC i dla doświadczonego programisty może wydawać sięoczywiste, jednak często nie jest to posunięte odpowiednio daleko:

- Jeśli twoje kontrolery obsługują więcej niż jeden model i modelete nie są w relacji rodzic-dzieci, jeśli wykonują jakiekolwiekoperacje nie związane bezpośrednio z obsługą żądania HTTP -są duże szanse, że robisz coś źle

- Nie trudno zauważyć, że większość takich kontrolerów (w końcuzajmujących się głównie odpowiadaniem na żadania HTTP i wyboremreprezentacji dla modelu!) i ich akcji (CRUD) naturalnie przekładasię na zbiór zasobów i operacji zdefiniowanych na nich za pomocąsemantyki HTTP - GET, PUT, POST, DELETE

- Wobec czego, Railsy 1.2 wprowdziły już dość rozbudowane, ale jeszczeniedopracowane wsparcie dla budowy RESTowych aplikacji

- Railsy 2.0 pozwalają zapomnieć o wszelkich niedogodnościachzwiązanych z serwowaniem treści z RESTowej aplikacji do "durnych"klientów, zachowując pozostałe zalety takich architektur

Rails - referencyjny framework dla RESTowych aplikacji #3

- Ani Rails, ani REST nie są "srebrnymi pociskami"

- I Rails i REST były tworzone ze względu na praktyczne potrzeby ichautorów z budowaniem aplikacji internetowych - są zoptymalizowanedla znaczącej większości zastosowań

- Alternatywne podejścia jak SOAP mają swoje miejsce i przewagi nadRESTem, ale nie w zastosowaniach do jakich przeznaczony jestRails, czyli takich, którymi większość z nas tutaj się zajmuje

- Używając Railsów bez dokładnego zrozumienia mechanizmów RESTowychtracimy połowe obrazu i sporo skuteczności

- A że wiele osób tak ich własnie używa, jako "drop-in", zamiennikdla PHP, umożliwiający jeszcze szybsze klepanie...

- Więc o tym mówimy

Zmiany w Rails 2.0

- Wydaje mi się, że większa część listy zmian w Rails 2, jak i zresztąw Rails 1.2 zaczyna mieć dla studiującego sens dopiero pozrozumieniu wszystkiego co wcześniej powiedziałem

- Na poparcie moich słów:

"As you might have gathered, Action Pack in Rails 2.0 is all aboutgetting closer with HTTP and all its glory."

Ojciec Założyciel David Heinemeier Hansson

Zmiany w Rails 2.0 - ActiveResource

require 'activeresource'

# Twoja stara postuje XML do "/statuses.json"class ActiveResource::Base

def to_json{ self.class.to_s.downcase => attributes }.to_json

end

def parametrizemethod(("to_" + self.class.format.extension).to_sym).call

end

def createreturning connection.post(collection_path, parametrize, self.class.headers) do

|response|self.id = id_from_response(response)load_attributes_from_response(response)

endend

end

class BlipResource < ActiveResource::Baseself.site = 'http://foo:dupa.8@localhost/'self.format = :json

endclass User < BlipResource; endclass Update < BlipResource; endclass Status < BlipResource; end

@user = User.find(:id => "foo")@statuses = Status.find(:all, :user_id => 'foo', :params => {:limit => 4})@new_status = Status.create(:body => "Witaj świecie!")

Zmiany w Rails 2.0 - Autentykacja HTTP

class PostsController < ApplicationControllerbefore_filter :authenticate, :except => [ :index ]

def indexrender :text => "Dla wszystkich"

end

def editrender :text => "Tylko dla znajomych :>"

end

privatedef authenticate

authenticate_or_request_with_http_basic do |user_name, password|user = User.find_by_name(user_name)user && user.password_hash == Digest::MD5.hexdigest(password)

endend

end

Zmiany w Rails 2.0 - łatwe odwołania do zasobów

Przed

<%= render :partial => 'update', :collection => @updates %><%= redirect_to(person_path(@person)) %><%= link_to(@person.name, person_path(@person)) %><%= form_for(:person, person_path(@person)) %><%= form_for(:person, person_path(@person), :html => { :method => :put }) %>

Po

<%= render :partial => @updates %><%= redirect_to(@person) %><%= link_to(@person.name, @person) %><%= form_for(@person) %><%= form_for(@person) %>

Zmiany w Rails 2.0 - abstrakcyjne formaty

# config/initializers/mime_types.rbMime.register_alias "text/html", :iphone

class ApplicationController < ActionController::Basebefore_filter :adjust_format_for_iphone

def adjust_format_for_iphoneuser_agent = request.env["HTTP_USER_AGENT"]request.format = :iphone if user_agent && user_agent[/(iPhone|iPod)/]

endend

class PostsController < ApplicationControllerdef index

respond_to do |format|format.html # renders index.html.erbformat.iphone # renders index.iphone.erb

endend

end

Zmiany w Rails 2.0 - filtry wykonujące się dla jednego typurequestu

class FajnyKontroler < ApplicationControllerbefore_filter do |c|

c.use_session_auth if c.request.format.html?c.use_token_auth if c.request.format.xml?

end

sessions :off, :if => Proc.new { |request| request.format.iphone? }end

# Btw, render i redirect w filtrach przerywają teraz wykonywanie akcji

Zmiany w Rails 2.0 - Lista rout w rake'u

# rake routes

from_subscriptions GET /subscriptions/from{:action=>"from", :controller=>"subscriptions"}

formatted_from_subscriptions GET /subscriptions/from.:format{:action=>"from", :controller=>"subscriptions"}

to_subscriptions GET /subscriptions/to{:action=>"to", :controller=>"subscriptions"}

POST /subscriptions{:action=>"create", :controller=>"subscriptions"}

PUT /subscriptions/:id{:action=>"update", :controller=>"subscriptions"}

Zmiany w Rails 2.0 - Odzielenie silinka renderującego odformatu odpowiedzi

Akcja.format.renderer

Czym innym jest format, czym innym silnik który go wspiera

Zmiany w Rails 2.0 - Fikstury z odwołaniami po nazwie

# Kiedyśsubscription:

id: 17tracking_user_id: 12tracked_user_id: 13transport_id: 4created_at: 2007-10-06 10:00:00

# Terazsubscription:

tracking_user: wiesiotracked_user: heniotransport: jabbercreated_at: 2007-10-06 10:00:00

# A także

assert_equal [updates(:foo), updates(:bar)], Update.find(:all)assert_equal updates(:foo, :bar), Update.find(:all)

Zmiany w Rails 2.0 - Zabezpieczenia przed atakami CSRF

- Wytłumaczenie ataku

- Akcje wykonywane przy pomocy PUT, POST i DELETE nie wykonują sięjeśli formularz nie zawiera tokena unikalnego dla każdegoużytkownika

- Wszystkie Railsowe helpery jak form_for, link_to z ustawionym methoditp. domyślnie dodają kod wysyłający token

Zmiany w Rails 2.0 - Nowa składnia migracji

# Kiedyścreate_table :people do |t|

t.column, "account_id", :integert.column, "first_name", :string, :null => falset.column, "last_name", :string, :null => falset.column, "description", :textt.column, "created_at", :datetimet.column, "updated_at", :datetime

end

# Terazcreate_table :people do |t|

t.integer :account_idt.string :first_name, :last_name, :null => falset.text :descriptiont.timestamps

end

Zmiany w Rails 2.0 - Sesje w cookies

- Sesje są teraz domyślnie trzymane po stronie klienta, w zaszyfrowanejpostaci, jako cookies

- Bardzo szybkie, w porządku przy umiarkowanym użyciu sesji

- Nie mogą zostać podmienione, ale mogą zostać podejrzane

- Limit 4k

Słowa Podsumowania

- Railsy nie są sukcesem czysto technologicznym...

- Są przedewszystkim pokazem tego, że aplikacje internetowemożna tworzyć inaczej - łatwiej, przyjemniej, bez ton XMLa,a jednocześnie trzymając się utartych standardów i z zyskiemje wykorzystując.

- Duży procent tej wizji przeniesiono do innych frameworków winnych językach, co po części dowodzi, że "wizja" ta jestgłównym "dziedzictwem" Railsów.

- Oczywiście nie przypadkiem Railsy powstały właśnie w Ruby - nadziś dzień to w tym języku taką wizję możemy wyrazić najbardziejnaturalnie.

- Ale za 10 lat będziemy mieli lepszy język, a wizja popchnęła doprzodu całą dziedzinę.

- Dziękujemy za Rails!

Wykorzystane zasoby

- "Architectural Styles and the Design of Network-based SoftwareArchitectures", Roy Fieldinghttp://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

- "Architecture of the World Wide Web, Volume One"http://www.w3.org/TR/webarch/

- RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1"http://www.ietf.org/rfc/rfc2616.txt

- RFC 2396 "Uniform Resource Identifiers (URI): Generic Syntax"http://www.ietf.org/rfc/rfc2396.txt

- Oficjalny anons Rails 2.0:http://weblog.rubyonrails.org/2007/12/7/rails-2-0-it-s-done

- Opis zmian w Rails 2.0 na blogu "Ryan's Scraps"http://ryandaigle.com/articles/2007/12/7/rails-2-0-final-released-summary-of-features

- Railscasts, w szczególności ostatnie odcinki o Rails 2http://railscasts.com/

- "Skinny controllers, fat models" - blog "the { buckblogs :here }"http://weblog.jamisbuck.org/2006/10/18/skinny-controller-fat-model