Jarosław Zabiełło - BLOG: Tag activerecord

Wściekły Zed i dyskusja wokół Rubiego i Railsów

Jarosław Zabiełło — Sun, 06 Jan 2008 23:49:00 +0100

Ostatnio jest trochę szumie w branży po bezpardonowym (i niewybrednym) ataku Zeda Shaw uderzającym w kilka znanych postaci z kręgów Rubiego i Rails. Pewnie nikt by na to nie zwrócił uwagi gdyby nie to, że Zed jest autorem znanego projektu Mongrel. Choć wpis się źle czyta (bo jest rozwlekły i niepotrzebnie przeplatany ciągłymi przekleństwami autora) to zwrócił uwagę na kilka istotnych problemów.

Autor zwraca uwagę, że core team Railsów dosyć opornie i wolno reaguje na podsyłane uwagi i poprawki. Fakt, jedną z poprawek jaką kiedyś podesłałem odnośnie źle działającej funkcji render_to_string uwzględniono po.. ośmiu miesiącach. Zed się wkurzył, że ignorowano jego uwagi a potem i tak wychodziło na jego. Tak z połowa core teamu to wg niego banda idiotów z wypłukanymi przez PHP mózgami. Ze swej strony bym mógł do tej listy niekompetencji owej “bandy” też coś dołożyć, ale to nie jest najważniejsze. Jest reszta, która dobrze robi swoją robotę. Ale może taka krytyka podziała jak kubeł zimnej wody i w końcu cały core team zacznie skupiać się na jakości i optymalizacji już istniejącego kodu. Bo jak nie, to programiści Rails zaczną sukcesywnie przesuwać się do konkurencyjnego projektu Merb. Ezra Zygmuntowicz udowodnił, że można napisać “lepsze Railsy” (szybsze, wielowątkowe i bardziej przejrzyste). Podoba mi się inżynieryjne podejście Ezry Zygmuntowicza. Jego Merb jest bardzo ładny, przejrzysty i szybki. Co ciekawe, Ezra zatrudnił kilku developerów Rubiniusa. Zapowiada się że Railsy w końcu spotkały bardzo trudną konkurencję (i bardzo dobrze). Sytuację Ralsów pogłębia to, że nowe ORM’y takie jak DataMapper i Sequel również stanowią zagrożenie dla dominacji Active Record nawet w kontekście Railsów.

PickAxe i inne książki

Zed przeprowadził bardzo ciekawą krytykę chwalonej PickAxe. Ostro rozjechał autora za używanie głupich przykładów, niezgodnego z konwencjami Rubiego nazewnictwem zmiennych, i co najważniejsze, ominięcie szerokim łukiem najważniejszej i najbardziej atrakcyjnej cechy Rubiego – łatwości metaprogramowania. PickAxe, zdaniem Zeda, odwołuje się do starych praktyk projektowania obiektowego z roku 2001. Zed idzie nawet dalej, uważa że ta książka promuje złe nawyki programistyczne i zachęca do pisania złego kodu. Twierdzi nawet, że ta książka zamiast pomóc, zaszkodziła Rubiemu aby wcześniej wypłynął na szeroką scenę.

Faktycznie, w latach 2001-2004 o Ruby praktycznie nikt nie słyszał. Jakieś nieliczne wyjątki uczyły się Rubiego na książce Dave’a Thomasa ale język jako taki był czymś bardzo malo znanym. Sytuację zmieniło dopiero pojawienie Ruby on Rails w 2005 roku, ktore spowodowały znaczący wzrost popularności Rubiego (ja sam też zainteresowałem się też Railsami, a dopiero później Rubim). Dopiero Railsy pokazały piękno i moc metaprogramowania w Ruby, coś co zachwyciło rzesze ludzi, coś czego nie mają inne języki. I nie wiem jak by się wysilano, nie da się uzyskać tak pięknego i eleganckiego metaproramowania w PHP, Javie, czy nawet Pythonie. Zed bezpardonowo stwierdził, że PickAxe tylko zaszkodził Rubiemu zamiast mu pomóc.

Wpierw mnie zaskoczyła ta opinia, ale później, jak się zastanowiłem, to muszę przyznać że dużo w tym racji. Nigdy do mnie nie przemawiały użyte w książce przykłady. Ceniłem ją głównie za to, że w ogóle jest cokolwiek na temat Rubiego, i że opisano bibliotekę standardową Rubiego. Jestem ciekaw, co Zed by powiedział na książkę Hala Fultona “The Ruby Way”. Jej drugie wydanie właśnie zostało wydane po polsku. Szkoda tylko, że ma w polskim wydaniu mylący tytuł sugerujący, że to tylko jakiś zestaw 400 przykładów. Książkę się dosyć dobrze czyta. Lepiej niż PickAxe. Tą pierwszą trochę traktuję jak podręcznik do bibliotek Rubiego.

Co ciekawe, dostało się też trochę książce Agile :) Ale generalnie dużo nie ma co się przyczepić. Książka jest raczej dobrze napisana, szkoda tylko, że opisuje starsze Rails 1.2 a nie 2.0. No cóż, nie wiadomo czy wyjdzie trzecie wydanie, bo DHH jakoś się do niego nie pali.

Z ciekawości sprawdziłem inną książkę, polecaną przez Zeda, The Rails Way. Faktycznie wygląda na dobrze napisaną i uwzględnia nowsze cechy Railsów. Jest dostępna online (choć nie za darmo) przez O’Reilly Safari Books Online (tak w ogóle to świetny serwis, który warto sobie zaprenumerować).

Rubinius, JRuby i Jubinius

Zed się wkurzył, nabluzgał, ale zwrócił uwagę na kilka ważnych kwestii. Także odnośnie samego Rubiego to pochwała dostała się JRuby i Rubiniusowi. Szczególnie ten drugi może wkrótce kompletnie zagrozić dominacji MRI jaki jest używany w dzisiejszej, opartej na C, implemementacji Rubiego. Jeśli szybko nie powstanie kompletnie ukończony YARV (włączony do Ruby 1.9), to Rubinius zwycięży. Temat Rubiniusa jest on tematem naszych dyskusji na kanale IRC #rubyonrails.pl. Podejście jest tu trochę podobne do pythonowego PyPy, choć Rubinius nawiązuje bardziej do 30 lat doświadczeń Smalltalka. Celem jest stworzenie najszybszej wirtualnej maszyny Rubiego oraz łatwego i szybkiego rozwoju dla samego Rubiego. Dzięki temu, że mamy tu do czynienia z Ruby którego implementacja napisana jest w Ruby, znacznie łatwiej jest rozwijać język.

Co ciekawe, autorzy JRuby zastanawiają się czy nie zrobić podobnie. I już są dyskusję o tym aby stworzyć analogicznie Jubiniusa. Tak jak Rubinius w łatwy sposób wciąga biblioteki napisane w C, Jubinius wciągałby te napisane w Javie. Jubinius miałby dodatkowo o tyle wygodniejszą sytuację, że implementacja całej biblioteki standardowej Rubiego jest już przepisana do Rubiego. Jubinius mógłby z marszu wykorzystać ten kod.

Sequel vs Active Record. Część 2 - integracja Rails z Sequelem

Jarosław Zabiełło — Fri, 21 Dec 2007 13:27:00 +0100

W pierwszej części trochę wypunktowałem słabe strony standardowego ORM’a używanego w Railsach. Najlepiej zastąpić go szybszym i ogólnie dużo lepszym Sequelem. Można to zrobić na kilka sposobów: całkowicie zastąpić Active Record lub używać Sequela obok Active Record – jak kto woli.

Zakładam, że na początek może byśmy chcieli popróbować Sequela tak, aby można było szybko przełączyć się z powrotem na Active Record. Po doinstalowaniu gema sequel , należy przejść do pliku config/environment.rb i dodać gdzieś następujący kod:

require 'sequel'
DB = Sequel 'mysql://login:haslo@localhost/nazwa_bazy'

Obiekt DB jest wielowątkowym połaczeniem z bazą definiowaną za pomocą URI. Jak ktoś, chce to można automatycznie zassać dane o bazie z pliku config/database.sql

require 'sequel'
conf = YAML.load_file(config.database_configuration_file)[ENV['RAILS_ENV']]
DB = Sequel "#{conf['adapter']}://#{conf['username']}:#{conf['password]}@#{conf['host']}/#{conf['database']}"

Następnie w modelu można dodać sobie warunek tak, aby trzymać obie wersje kodu, dla AR i dla Sequela (potem można wywalić to, co nie jest potrzebne).

if DB
  # Wersja dla Sequel
  class Preference < Sequel::Model(:preferences)
    def user
      User.filter(:id => user_id)
    end
  end
else 
  # Wersja dla Active Record
  class Preference < ActiveRecord::Base
    belongs_to :user
  end
end

Zamiast metody user można użyć makra one_to_one :user, :from => :User ale ja wolę stworzyć własną metodę. Robi nie tylko to samo, ale także nie trzeba pamiętać dodatkowych opcji w razie nietypowej struktury. Poza tym w podanym przykładzie zwracany jest obiekt proxy, a nie lista obiektów. Daje to możliwości poza zasięgiem Active Record. Mogę rozbudowywać zwracany obiekt o kolejne metody. Na każdym etapie mam podgląd do wygenerowanego SQL’a.

Preference.first.user.sql
=> "SELECT * FROM users WHERE (`id` = 1)"

Preference.first.user.order(:name).sql
=>  "SELECT * FROM users WHERE (`id` = 1) ORDER BY `name`"

Preference.first.user.order(:name).select(:users.all).sql
=> "SELECT users.* FROM users WHERE (`id` = 1) ORDER BY `name`"

Albo inny przykład

class Post < Sequel::Model(:posts)
  def dataset.old_posts
    filter {:stamp < 30.days.ago}
  end    
  def dataset.clean_old_posts
    old_posts.delete
  end
end

I można teraz napisać tak:

Post.filter(:category => 'ruby').clean_old_posts

Szybki start z Rails, Merb i Pylons

Jarosław Zabiełło — Sun, 16 Dec 2007 07:31:00 +0100

Celem tego tekstu jest porównanie podstawowych czynności niezbędnych do tego aby uruchomić Rails, Merb oraz Pylons. Zakładam że używany będzie

Rails (v2.0.1) + Active Record + Haml
Merb (v0.4.2)+ Sequel (v0.4.3) + Haml
Pylons (v0.9.6.1) + SQLAlchemy + Mako

Wpierw musimy (jeśli jeszcze nie mamy) poinstalować stosowne biblioteki. W wypadku Rails i Merba musimy mieć Rubiego i RubyGems oraz doinstalowane gemy:

gem install -y rails haml merb sequel merb_sequel

W wypadku Pylons musimy mieć zainstalowanego Pythona oraz pakiet setuptools dający możliwość używania skryptu easy_install (taki odpowiednik RubyGems dla Pythona)

easy_install Pylons SQLAlchemy Mako

Tworzenie projektu:

Rails

rails rails_app

Merb

merb merb_app

Pylons

paster create -t pylons pylons_app

Podpięcie do bazy

Rails

Należy w pliku config/database.yml wpisać:

shared: &shared  
  adapter: mysql
  encoding: utf8
  username: login
  socket: /opt/local/var/run/mysql5/mysqld.sock
  password: haslo
development:
  database: rails_app
  <<: *shared
test:
  database: test
  <<: *shared
production:
  database: rails_app
  <<: *shared

Merb

Tu jest tak samo jak w Rails z tą różnicą, że nie ma tego pliku. Należy stworzyć Plik config/database.yml:

---
  shared: &shared  
    :adapter: mysql
    :encoding: utf8
    :username: login
    :socket: /opt/local/var/run/mysql5/mysqld.sock
    :password: haslo
  development:
    :database: merb_app
    <<: *shared
  test:
    :database: test
    <<: *shared
  production:
    :database: merb_app
    <<: *shared

Pylons

Tu, niestety, jest większa zabawa, bo zarówno Pylons jak i SQLAlchemy są bardziej złożone.

W pliku development.ini wstawiamy:

sqlalchemy.url = mysql://user:haslo@localhost:3306/pylons_app
sqlalchemy.echo = True
sqlalchemy.pool_recycle = 3600

Warto zwrócić uwagę, że parametr ‘pool_recycle’ zabezpiecza nas przed pewnym problemem w MySQL. Otóż po paru godzinach nieaktywności, potrafi zrywać zestawione wcześniej połączenie. SQLAlchemy zabezpiecza się przed tym stukając do bazy co godzinę. Active Record nie ma przed tym standardowo wbudowanego zabezpieczenia (sic!). Sequel zaś (też – jak SQLAlchemy- pracujący wielowątkowo) wyłapuje zerwane połączenia, czyści je i zestawia z powrotem.

Musimy ustawić sesję dla SQLAlchemy. Działa i czyści się po każdym przeładowaniu przeglądarki internetowej. W pliku pylons_app/lib/base.py wpisujemy:

# reszta pliku...
import pylons_app.model as model

class BaseController(WSGIController):

    def __call__(self, environ, start_response):
        """Invoke the Controller"""
        conn = config['pylons.g'].sa_engine.connect()
        model.Session(bind=conn)
        try:
            return WSGIController.__call__(self, environ, start_response)
        finally:
            model.Session.remove()
            conn.close()
# reszta pliku...

Tworzenie modeli

Rails

W Rails korzystamy z wbudowanych generatorów kodu:

$ script/generate model User
-> app/models/user.rb
...
-> db/migrate/001_create_users.rb

$ script/generate model Post
-> app/models/post.rb
...
-> db/migrate/002_create_posts.rb

Razem z modelami domyślnie są tworzone pliki z migracjami. Wpierw jednak zdefiniujmy relacje między modelami:

Plik app/models/post.rb:

class Post < ActiveRecord::Base
  belongs_to :user
  # Albo to samo za pomocą tych metod:
  # def user
  #   User.find :first,:conditions => ["id=?", id]
  # end
  # def user=(item)  
  #   self.user_id = item.id
  # end
end

Plik app/models/user.rb:

class User < ActiveRecord::Base
  has_many :posts
  # Albo to samo bardziej bezpośrednio:
  # def posts
  #  Post.find :all, :conditions => ["user_id=?", id]
  # end
end

Zdefiniujemy nie tylko struktury tabel ale też wypełnimy je przykładowymi danymi.

Plik db/migrate/001_create_users.rb:

class CreateUsers < ActiveRecord::Migration
  def self.up
    create_table :users, :force => true do |t|
      t.string :name, :null => false
    end
    add_index :users, :name, :unique => true
    User.create! :name => 'Jarek'
  end
  def self.down
    drop_table :users
  end
end

Plik db/migrate/001_create_posts.rb:

class CreatePosts < ActiveRecord::Migration
  def self.up
    create_table :posts, :force => true do |t|
      t.integer :user_id, :null => false
      t.string :title, :null => false
      t.text :body
      t.timestamps
    end
    add_index :posts, :title, :unique => true
    post = Post.new
    post.title = 'Tytuł artykułu'
    post.body = 'Treść artykułu'
    post.user = User.find_by_name('Jarek')
    post.save!    
  end
  def self.down
    drop_table :posts
  end
end

Uruchamiamy migracje:

rake db:migrate

Sprawdźmy interaktywnie (w konsoli, czyli po odpaleniu ruby script/console) czy modele działają prawidłowo.

User.find :all
# => [#<User id: 1, name: "Jarek">]
User.find(:first).posts
# => [#<Post id: 1, user_id: 1, title: "Tytuł artykułu", body: "Treść artykułu", created_at: "2007-12-15 18:16:27", updated_at: "2007-12-15 18:16:27">]
User.find(:first).posts[0].title
# => "Tytuł artykułu"

Merb

Tu wpierw trzeba wybrać jaki ORM chcemy używać (domyślnie Merb nie ma właczonej obsługi żadnego). Operacja jest bardzo prosta. W pliku config/dependencies.rb odkomentujemy linijkę tak aby było:

use_orm :sequel

Modele generujemy identycznymi generatorami jak w Rails.

$ script/generate model User
-> app/models/user.rb
...
-> schema/migrations/001_add_model_users.rb

$ script/generate model Post
-> app/models/post.rb
...
-> schema/migrations/002_add_model_posts.rb

Definicja modeli.

class Post < Sequel::Model(:posts)
  one_to_one :user, :from => :Post
  # To samo co:
  # def user
  #   User.filter(:id=> user_id).first
  # end  
  # def user=(obj)
  #   self.user_id = obj.id
  # end  
  #
  # Merb nie ma automagicznego wypełniania treścią
  # pól o nazwach created_at czy updated_at
  # Ale posiada wywołania zwrotne (też jak Rails)
  after_create do
    set(:created_at => Time.now)
    set(:updated_at => Time.now)
  end
  after_update do
    set(:updated_at => Time.now)
  end
end

class User < Sequel::Model(:users)
  one_to_many :posts, :from => :posts, :key => :user_id
  # To samo co:
  # def posts
  #   Post.filter :user_id => pk
  # end
end

W przeciwieństwie do Active Record, w Sequelu można zdefiniować (metodą set_schema) strukturę tabel w modelu (wtedy nie trzeba np. zaglądać do migracji ani bazy, aby sobie przypomnieć strukturę tabeli). Ale aby oszczędzić sobie pisania, zdałem się tu na automatyczne rozpoznanie struktury tabel przez Rubiego.

Teraz pora na migracje. Sequel też je posiada, choć różnią się troszkę składnią do tych w Active Record.

Plik schema/migrations/001_add_mode_users.rb:

class AddModelUsers < Sequel::Migration
  def up
    create_table! :users do
      primary_key :id
      varchar :name, :size => 255, :unique => true      
    end  
    User.create :name => 'Jarek'
  end
  def down
    execute 'DROP TABLE users'
  end
end

Plik schema/migrations/002_add_mode_posts.rb:

class AddModelPosts < Sequel::Migration
  def up
    create_table! :posts do      
      primary_key :id 
      integer :user_id, :null => false
      varchar :title, :null => false, :unique => true
      text :body
      datetime :created_at 
      datetime :updated_at 
    end    
    post = Post.new
    post.title = 'Tytuł artykułu'
    post.body = 'Treść artykułu'
    post.user = User.filter(:name=>'Jarek').first
    post.save
  end
  def down
    execute 'DROP TABLE posts'
  end
end

Uruchomienie migracji działa w Sequelu tak samo jak w Active Record (nawet parametr VERSION też tu działa).

rake sequel:db:migrate

No to pora na test z interaktywnej konsoli. Odpala się ją przez:

merb -i

User.all
# => [#<User:0x19477e8 @changed_columns=[], @values={:name=>"Jarek", :id=>1}, newfalse]
User.first.posts.class 
# => Sequel::MySQL::Dataset
# User.first.posts.sql
# => "SELECT * FROM posts WHERE (`user_id` = 1)"        
User.first.posts.first.title
# => "Tytu\305\202 artyku\305\202u"

Sequel nie tylko jest szybszy i używa iteratorów (oszczędzająć przez to pamięć). Jest też wielowątkowy (używa puli wątków) oraz pozwala na krokowy podgląd kodu SQL przed jakimkolwiek przeslaniem kwerendy do bazy danych. Sequel również nie zwraca liste obiektow ORM z bazy (jak Active Record) ale jeden, specjalny obiekt proxy. Pozwala to na interaktywne budowanie kodu w stopniu o wiele lepszym niż pozwala na to Active Record (czy nawet DataMapper). Sequel ma również wbudowany cache modeli współpracujący z szybkim serwerem memcached.

Pylons

Poniższa konfiguracja jest inspirowana tekstem SQLAlchemy 0.4 for people in a hurry. Pylons nie wymaga aby każdy model był w oddzielnym pliku, zatem użyjemy jednego. W pliku pylons_app/model/init.py wpisujemy:

# -*- coding: utf8 -*-
from datetime import datetime

# Zgodnie z filozofią Pythona, importujemy tylko tylko interesujące nas symbole
# aby nie zaśmiecać sobie przestrzeni nazw:

from pylons import config
from sqlalchemy import ForeignKey, Column, MetaData, Table, types
from sqlalchemy.orm import mapper, relation
from sqlalchemy.orm import scoped_session, sessionmaker

Session = scoped_session(sessionmaker(autoflush=True, transactional=True, bind=config['pylons.g'].sa_engine))
metadata = MetaData()

# Tworzymy definicje tabel:

table_users = Table('users', metadata,
  Column('id', types.Integer, primary_key=True),
  Column('name', types.String(255))
  )
table_posts = Table('posts', metadata,
  Column('id', types.Integer, primary_key=True),
  Column('user_id', types.Integer, ForeignKey('users.id')),
  Column('title', types.Unicode(255)),
  Column('body', types.Unicode),
  Column('created_at', types.DateTime, default=datetime.now),
  Column('updated_at', types.DateTime, default=datetime.now)
  )
# Zamiast tego można automatycznie wciągnąć istniejącą strukturę:
#
# table_users = Table('users', metadata, autoload=True)
# table_posts = Table('posts', metadata, autoload=True)

# Tworzymy definicje modeli.

class User(object):
    pass
class Post(object):
    pass

# Mapowanie ORM do klas SQLAlchemy i ustawienie
# relacji jeden-do-wielu
mapper(User, table_users, properties={'posts':relation(Post, backref='user')})
mapper(Post, table_posts)

Wygląda to bardziej skomplikowanie, ale SQLAlchemy ma też większe możliwości. Zasadniczą różnicą w SQLAlchemy jest rozdzielenie obiektów ORM od obiektów modelu biznesowego. Obiekty ORM zajmują się mapowaniem struktur tabel do obiektów Pythona. Są one następnie łączone z klasami SQLAlchemy. Takie rozdzielenie daje dużo większe możliwości, bo można w modelu biznesowym nawet zamapować kilka tabel do jednego modelu. SQLAlchemy ma dużo innych możliwości, o których tu nie będę teraz pisać. W każdym razie odbija się to na złożoności (ale i tak to jest prościej niż np. w javowym Hibernate).

Co z migracjami? Nie ma ich. Trzeba by było je napisać (to w sumie nie jest trudna sprawa). Stworzmy jednak strukture tabel wraz z przykładowymi danymi za pomocą SQLAlchemy. W tym celu końcówka pliku pylons_app/websetup.py powinna wyglądać następująco:

# początek pliku…

def setup_config(command, filename, section, vars):
    """Place any commands to setup pylons_app here"""
    conf = appconfig('config:' + filename)
    load_environment(conf.global_conf, conf.local_conf)

    from pylons_app.model import metadata, Session, User, Post

    log.info("Creating tables")
    metadata.create_all(bind=config['pylons.g'].sa_engine)
    log.info("Successfully setup")

    log.info("Adding some data to table 'users'")
    user = User()
    user.name = 'Jarek'
    Session.save(user)
    Session.commit()

    log.info("Adding some data to table 'posts'")
    user_query = Session.query(User)
    user_id = user_query.filter(User.name == 'Jarek').one().id
    post = Post()
    post.title = 'Tytuł artykułu'
    post.body = 'Treść artykułu'
    post.user_id = user_id
    Session.save(post)
    Session.commit()    
    log.info("Data added.")

W powyższym przykładzie widać też próbkę sposobu w jaki używa się SQLAlchemy. Każda operacja jest zamykana w ramach specjalnej sesji a sesja jest tworzona niezależnie dla każdego wątku. W SQLAlchemy praktycznie w ogóle nie ma potrzeby sięgania do kodu SQL tak jak to nagminnie widać w Active Record. Choć muszę też przyznać, że Sequel także ładnie daje sobie radę ze skomplikowanymi konstrukcjami bez konieczności uciekania się do surowego kodu SQL.

Uruchamiamy tworzenie tabel za pomocą:

paster setup-app development.ini

Interaktywny shell uruchamia się przez

paster shell

Trzeba pamiętać, że fakt uruchomienia konsoli nie oznacza, że mamy automatycznie powciągane moduły wszystkich modeli. W Pythonie nie ma magii, wszystko należy jawnie zaimportować. Także i nasz projekt.

from pylons_app import *
print model.User
# => <class 'pylons_app.model.User'>

Tworzenie kontrolera i prostego widoku.

Rails

script/generate controller home
# => app/controllers/home_controller.rb

Plik kontrolera (app/controller/home_controller.rb):

class HomeController < ApplicationController
  def index
    @user = User.find :first
  end
end

Aby użyć Haml zamiast ERb musimy w katalogu projektu odpalić komendę (nie zapomnij o kropce, która oznacza tu bieżący katalog):

haml --rails .

Plik widok (app/views/home/index.html.haml):

Użytkownik
= @user.name
posiada post(y)
%ul
  - @user.posts.each do |post|
    %li= post.title

Serwer uruchamiamy klasycznie

script/server

Merb

script/generate controller home
# => app/controllers/home.rb

Plik kontrolera (app/controllers/home.r):

class Home < Application
  def index
    @user = User.first
    render
  end
end

Aby uaktywnić Haml należy w pliku config/merb_init.rb dopisać na końcu

Merb::Template::Haml

Warto też doinstalować gemy:

gem install -y merb_helpers merb_has_rails_plugins ruby-debug

i dodać je do config/dependencies.rb

dependency 'merb_helpers'
dependency 'merb_has_rails_plugins'
dependency 'ruby-debug'

Dzięki temu będziemy mieli dostępnych trochę dodatkowych helperów z Rails. Zaś gem ruby-debug umożliwia nam wpisanie w dowolnym miejscu komendy debugger przerywającej pracę przeglądarki i kierującej wykonanie kodu do konsoli. Po jej zakończeniu przeglądarka wznawia obsługę requestu. Działa to tu tak jak w Rails. Można interaktywnie sobie operować na żywym kodzie. Warto też wiedzieć, że w Merb wszystkie pluginy są po prostu gemami. Ułatwia to zarządzanie ich wersjami.

Plik widoku jest identyczny jak w wyżej dla Railsow więc nie będę podawał jeszcze raz jego treści.

Odpalamy serwer za pomocą komendy merb i na stronie http://localhost:4000/home podziwiamy wynik. :) Komenda merb—help wyświetli wszystkie, dostępne opcje.

Pylons

paster controller home
# => pylons_app/controllers/home.py

Plik kontrolera (pylons_app/controllers/home.py):

import logging
from pylons_app.lib.base import *
log = logging.getLogger(__name__)
from pylons_app.model import Session, User

class HomeController(BaseController):
    def index(self):
        user_query = Session.query(User)
        c.user = user_query.filter(User.name == 'Jarek').one()
        return render('/home/index.mako')

Plik widoku (pylons_app/templates/home/index.mako):

Użytkownik ${c.user.name} posiada post(y)
<ul>
  % for post in c.user.posts:
    <li>${post.title}</li>
  % endfor
</ul>

Odpalamy serwer za pomocą

paster serve development.ini --reload

Pylons nie posiada trybów pracy tak jak Rails czy Merb. Wielowątkowy serwer HTTP (paster) musi dostać odpowiedni plik konfiguracyjny. Daje to w sumie więcej możliwości, bo można izolować sobie różne konfiguracje dużo bardziej niż prosty podział na tryb produkcyjny i rozwojowy.

Podsumowanie.

Rails jest bardzo bogato wyposażony w różne helpery, posiada dobrą literaturę, książki itd. Jest też bardzo łatwy do nauki i dosyć intuicyjny. Jeśli chodzi o prototypowanie, to jest prawie nie do pobicia. Niestety, można się przyczepić do jakości implementacji wewnętrznej jak i do niektórych błędów projektowych w Active Record. Myślę, że Railsom wyrósł bardzzo groźny konkurent w postaci Merba. Jest lepiej zorganizowany, spójniejszy i szybszy. Jest też tak samo prosty i intuicyjny. Czy warto się przesiadać? Wg mnie – warto. Jeśli zaś chodzi o ORM, to Sequel jest pod wieloma względami lepszym projektem od Active Record. Tu może tego nie eksponowałem, ale Sequel pozwala na obiektowe budowanie znacznie bardziej skomplikowanych zapytań niż to potrafi Active Record czy DataMapper. Po przykłady kodu Sequela odsyłam do jego strony domowej.

Co z Pylons? Korzysta z potężnego ORM’a i potężnych szablonów. Ma pełną obsługę Unicode, szablony Mako natywnie pracują na obiektach unikodowych (nie mylić ze stringami utf8). Mako mają dziedziczenie, potężny, elastyczny cache i są bardzo “pythonic” w swym podejściu do budowania modułów czy custom tagów. Niestety Pylons w całości wymaga trochę więcej wiedzy i umiejętności aby go ustawić do pracy. Rails i Merb są tu znacznie prostsze. Dzięki zaś Merb przepaść między wydajnością i możliwościami pythonowego Pylonso a frameworkami Rubiego mocno się zmniejszyla. Ci, co czepiali się wcześniej wydajności Rails nie mają teraz specjalnie na co narzekać. Ci co narzekali na ograniczenia Active Record, nie mają wymówki w zetknięciu z Sequelem. No chyba, że ktoś nie chce się uczyć Rubiego, jego sprawa. Ja jednak uważam, że Ruby to piękny język i bardzo przyjemnie się w nim pisze. A prostota Merba w porównaniu z Pylons jest (szczególnie dla osób zaczynających pracę) – powalająca.

Celem tego tekstu było pomóc osobom w początkowej fazie konfiguracji Pylons oraz Merb. Mam nadzieję, że był pomocny i dalej już każdy sobie sam da radę. Jeśli chodzi o dodatkową pomoc, to warto zajrzeć na IRC. Na serwerze freeenode istnieją kanały: #pylons, #merb, #sequel, #datamapper, #rubyonrails oraz nasze polskie #rubyonrails.pl i #python-pl. Są też polskie grupy dyskusyjne w Usenecie: news://pl.comp.lang.python i news://pl.comp.lang.ruby.

Kod źródłowy z powyższymi przykładami można pobrać stąd

Sequel vs Active Record. Część 1 - słabości AR.

Jarosław Zabiełło — Thu, 13 Dec 2007 00:37:00 +0100

Gdy framework Ruby on Rails (dalej: RoR lub Rails) rozpoczynał swoją błyskotliwą karierę, zachwycał wszystkich prostotą i elegancją konstrukcji. Jednym z fundamentalnych modułów Railsów jest Active Record, biblioteka realizująca symulację wirtualnej bazy obiektowej, pozwalającą na pracę z relacyjnymi bazami danych za pomocą obiektów języka Ruby. Active Record (dalej AR) nie uniknął jednak kilku potknięć projektowych.

Brak parametryzowanych zapytań SQL

Kompletnie nie rozumiem po co Active Record męczy się z budowaniem całej kwerendy SQL. Po co też jego tworcy tracą czas na walkę z analizą i odpowiednim escape’owaniem znaków w danych przekazywanych do zapytania. Przecież sterownik MySQL do Rubiego bez problemu to wszystko zrobi na nich! Mało tego, używanie parametryzowanych zapytań SQL jest szybsze niż samodzielne budowanie całego stringa i wykonywanie na nim kwerendy.

Brak iteratorów

Inną tajemnicą developerów AR jest brak korzystania z iteratorów. Zamiast tego AR, z uporem godnym lepszej sprawy, przepycha przez pamięć całą listę obiektów Rubiego. Im pobieramy więcej rekordów z bazy tym więcej obiektów musimy przesłać do pamięci (bo każdemu rekordowi odpowiada jeden egzemplarz klasy Active Record). AR wrzuca więc wszystkie obiekty ORM do pamięci. Trochę to bez sensu, bo bazy danych są optymalizowane na pobieranie rekordów małymi porcjami. Grupowane pobieranie/wkładanie rekordów potrafi być nawet o dwa rzędy wielkości szybsze. Gdyby DHH i koledzy popatrzyli dokładniej na standard PEP249 Pythona a nie na chaotyczne praktyki rodem z PHP, to by takiego błędu nie popełnili.

Domyślne SELECT * i błąd w :include

Gdy AR wykonuje zapytanie komendę Model.find(:all) to domyślnie wykonuje “SELECT *...” Nie byłoby z tym problemu gdyby nie to, że MySQL nie potrafi indeksować pół typu TEXT/BLOB. Pobieranie “hurtem” wszystkich kolumn z których jedna jest tego typu, dramatycznie spowalnia bazę danych.

No dobrze, ktoś powie, że można zawsze użyć opcji :select i wybrać sobie pola jakie chcemy. Niestety to się sypie, gdy chcemy użyć opcji :include aby uzyskać LEFT OUTER JOIN. Użycie opcji :include anuluje bowiem efekt działania opcji :select. (Aby to obejść trzeba zastąpić opcję :include opcją :joins i wklepać ręcznie cały fragment SQL. Opcja :joins nie koliduje z :select).

Niespójność składni :include i :joins.

To może mała sprawa, ale razi. Dlaczego :include pozwala na stosowanie ładnego zapisy :include => [:tabela1, :tabela2] a :joins przyjmuje tylko wartość typu String, tj. czysty SQL?

Aktualizacja jednej kolumny to aktualizacja wszystkich kolumn rekordu.

To już jest bardziej denerwujące. Chcemy zmienić fragment rekordu a AR serwuje nam update na wszystkich kolumnach. Nie ma jak to obejść bez uciekania się do odpalenia czystego SQL’a. Całe szczęście że AR na to pozwala.

Brak obsługi złożonych kluczy obcych

AR domyślnie w ogóle nie obsługuje złożonych kluczy obcych (Sympatycy pythonowego Django nie mają tu też powodu do dumy, bo ich ORM również tego nie potrafi). Sytuację trochę ratuje gem/plugin composite_primary_keys ale jak to z pluginami w Rails bywa, im ich mniej tym lepiej. No chyba, że ktoś sam prosi się o kłopoty. Z jakością pluginów jest różnie i trzeba ostrożnie je dobierać.

Brak krokowego budowania warunków

To jest jedna z bardziej denerwujących rzeczy. AR gromadzi warunki w wartości do klucza/opcji :conditions. Może on przyjmować wartość typu String, Array lub Hash ale tylko jedną naraz i tylko raz. Jeśli chcemy zbudować jakiś bardziej złożony warunek, to musimy sklejać sobie ręcznie kwerendę i uważać aby sobie przypadkiem nie strzelić jakimś przypadkowym sql-injection w stopę.

Nie wiem czy jest nadzieja na szybką poprawę jakości implementacji Active Record, bo mam wrażenie że developerzy i kontrybutorzy skupieni wokół tego frameworka wolą gonić za nowymi funkcjami zamiast zatrzymać się i dopracować to, co już stworzono. Na szczęście nie trzeba czekać. Active Record doczekał się godnych następców. Najbardziej znaczące są dwa: DataMapper i Sequel. Szczególnie godny uwagi jest Sequel. Ale o tym w następnej części.

Zobacz Sequel vs Active Record. Część 2 – integracja Rails z Sequelem

Ulepszony String i sprawa parametrów

Jarosław Zabiełło — Fri, 29 Jun 2007 02:42:00 +0200

Ruby posiada bardzo bogate możliwości przetwarzania tekstu. Zasugerowany składnią Active Record i wcześniejszym doświadczeniem z Pythonem trochę się zdziwiłem, że Matz nie zaimplementował przekazywania hasza do operatora %.

Parametry w Active Record.

Co prawda Active Record nie miał może nigdy ambicji kompletnego pozbycia się języka SQL, ale na tle takiego SQLAlchemy wypada znacznie mniej obiektowo¹. Widać to po sposobie budowania warunków. Active Record umożliwia przekazywanie parametrów do warunków na trzy podstawowe² sposoby.

“Chamskie” budowanie stringu SQL

Ta metoda jest najbardziej popularna u wszelkiej maści lamerów i osób początkujących. Jest bardzo powszechna wśród pehapowców, którzy niedawno zaczęli bawić się Railsami. Przykładowy kod tego typu wyglądałby mniej więcej tak:

user, passwd = params['user'], params['passwd']
Model.find :all, :conditions => "user='#{user}' AND login='#{passwd}'"

Taka “radosna tfurczość” jest z całą pewnością zaproszeniem do klasycznego ataku SQL Injection. Rails posiada co prawda funkcję sanitize_sql() która pacyfikuje niebezpieczne znaki w kwerendzie SQL, ale można o niej zapomnieć, a kod staje się po prostu brzydki. Zatem tego typu praktyce mówimy stanowcze: fuj!

Prawie wszystkie relacyjne bazy pozwalają na budowanie parametryzowanego SQL’a. Na tym bazują dwie kolejne metody.

Przekazywanie listy.

Warunek :conditions może przyjmować zarówno String jak i Array. W tym drugim wypadku dostajemy za darmo kod uodporniony na atak SQL Injection. Nie trzeba pamiętać o tym czy dane zawierają jakieś niebezpieczne znaki. Nie trzeba też zastanawiać się czy przekazywny parametr jest liczbą, czy stringiem (wymagającym apostrofów w kodzie SQL). Kod jest więc i prostszy i bezpieczniejszy.

user, passwd = params['user'], params['passwd']
Model.find :all, :conditions => ["user=? AND login=?", user, passwd]

Przekazywanie hasza.

Przekazywanie listy ma pewną wadę: trzeba pamiętać o kolejności parametrów. Także zawiera niepotrzebną redundancję w wypadku kiedy jakiś parametr musi się powtarzać. Dlatego Active Record umożliwia korzystanie ze składni inspirowanej bazą Oracle.

user, passwd = params['user'], params['passwd']
Model.find :all, :conditions => ["user=:user AND login=:login", {:user => user, :passwd => passwd}]

lub jeszcze krócej:

Model.find :all, :conditions => ["user=:user AND login=:login",params]

Parametry do stringa.

Po tym wstępie, pora na (niemiłą) niespodziankę jaką spotkałem w implementacji Rubiego. Generalnie Ruby posiada bardzo bogate możliwości przetwarzania tekstu. Podobnie jak Python, posiada też skróconą formę funkcji sprintf realizowaną za pomocą operatora %.

puts "%s can use %s." % ['Ruby', 'list of parameters']
=> "Ruby can use list of parameters."

Python jednakże pozwala także na używanie słowników.

params = {'lang':'Python', 'what':'a dictionary'}
print "%(lang)s can also use %(what)s." % params
Python can also use a dictionary.

Trochę mnie zdziwiło, że Ruby nie posiada odpowiednika tej funkcjonalności…. Na szczęście, dzięki otwartym klasom, monkey patching w przypadku Rubiego nabiera zupełnie innego wymiaru. Nic nie stoi na przeszkodzie aby ulepszyć standardowy obiekt String.

class String  
  alias_method :old_percent, :%
  # Template strings. 
  # Inspired by Python %(key)s and $key syntax.
  def % var
    if var.class == Hash
      var.each_pair do |key, value|
        if key.to_s =~ /^[a-z]+$/
          self.gsub! "$(#{key})", value.to_s
          self.gsub! "$#{key}", value.to_s
        end
      end
    end    
    old_percent var
  end
end

hash = {:lang => 'Ruby', :what => 'a hash'}
puts "Now $lang can also use $what :)" % hash
=> "Now Ruby can also use a hash :)"

I jak tu nie powiedzieć, że Ruby jest piękny? :)

¹ Active Record jest też mniej zaawansowany niż np. SQLAlchemy. Funkcjonalność Active Record jest może i świetna, ale jego implementacja w wielu punktach jest z pewnością niedojrzała. Np. nie mam pojęcia dlaczego Active Record zwraca listę obiektów zamiast generator, to pozwoliłoby na większe oszczędności pamięci.

² Bardziej obiektowe budowanie warunków zapewniają pluginy ez_where i Condition Builder.