Piotr Sarnacki

Ruby debug

2012-03-25T00:00:00-07:00

Debugger to bardzo ciekawe narzędzie. Bywa niezwykle pomocny przy różnego rodzaju problemach ciężkich do rozwiązania manualnie, ale stosunkowo niewiele osób go używa. I nawet jeżeli ktoś wie o jego istnieniu i wie jak z niego korzystać, to bez takiego nawyku, wiedza ta na niewiele się zdaje. Wyobraźmy sobie taką sytuację. Próbuję poprawić buga znalezionego w kodzie, więc piszę padający test i zaczynam wprowadzanie poprawki. Nie widzę żadnej anomalii patrząc w kod, więc zaczynam przyglądać mu się bliżej. I wbrew temu co mogą niektórzy powiedzieć, ten kod wcale nie musi być skomplikowany. Ruby jest językiem dynamicznie typowanym, więc bardzo często błędy w kodzie biorą się stąd, że dostajemy nie to co chcieliśmy. W takim wypadku, nawet przy bardzo prostym kodzie, możemy siedzieć nad rozwiązaniem dłuższą chwilę, bo umysł podświadomie omija problematyczne miejsce zakładając, że dostajemy oczekiwaną wartość. Wracając do poprawki, zaczynam wstawiać w różne miejsca w kodzie metody, które wyświetlą dane pomocne przy debugowaniu, najczęściej robię to w taki sposób:

def method_with_bug(value)

p [:value, value]

# ....
end

Dzięki użyciu metody p wyświetlona wartość będzie jeszcze potraktowana inspect. Jeżeli kilka takich linijek załatwi sprawę, to jesteśmy w domu, ale jeżeli nie? Najprawdopodobniej po każdym kolejnym dodanym p trzeba będzie uruchomić jeszcze raz test i być może okaże się, że będziemy musieli sprawdzić kilkanaście różnych rzeczy.

Debugger ma nad tego typu podejściem dość dużą przewagę - kiedy idziemy przez kod wykonując kolejne kroki, łatwiej jest zauważyć, że coś jest nie tak. Wyświetlając część danych na ekran, nie wiemy tak naprawdę gdzie siedzi błąd, więc trochę strzelamy. I nie chcę przez to powiedzieć, że przy każdym błędzie opłaca się odpalać debuggera, Warto po prostu mieć nawyk jego używania. Ja z reguły zaczynam od wyświetlenia kilku wartości, które są najbardziej podejrzane i mogą mi pokazać gdzie leży błąd i jeżeli to nic nie daje, to używam debuggera. Nawyk jest tutaj bardzo ważny, bo bez niego najczęściej skończy się na dodawaniu kolejnych puts, za każdym razem poprzedzonych myślą: "Ok, już wiem o co chodzi, tylko jeszcze wyświetlę ten obiekt, nie ma sensu włączać ruby-debug".

Jeżeli chodzi o przeciwników debuggera, to jednym z głównych zarzutów jest: "Używając debuggera można uniknąć dyscypliny, która powinna towarzyszyć nam przy programowaniu i tym samym ominąć kroki, które bez debuggera trzeba by wykonać: pisanie testów, refactoring, dodanie dokumentacji". Zgadzam się z tym, że w przypadku kiedy kod jest marnej jakości, nie ma do niego testów i dokumentacji, to użycie debuggera bez poprawy sytuacji jest błędem. Problem w tym, że sytuacja nie zawsze tak wygląda i debugger wcale nie oznacza porzucenia testów (o czym będzie jeszcze za chwilę). Jeżeli chodzi o refaktoryzację, to też jestem zwolennikiem jak najczęstszego jej stosowania, ale to nie zawsze jest możliwe. Czasami ze względu na czas, czasami ze względu na dużą ilość kodu, czasami ze względu na małą wiedzę o kodzie (np. stara aplikacja, którą musimy utrzymywać). Ale żeby nie przedłużać zostawię tego typu rozważania i przejdę do sedna.

Do czegu używam debuggera?

Użycie debuggera wygląda z reguły w ten sposób, że w momencie kiedy chcemy poprawić jakiś problem w aplikacji, to wstawiamy tam debugger, odpalamy aplikację (albo w przypadku aplikacji np. w railsach odświeżamy stronę w przeglądarce) i sprawdzamy co się dzieje. Ja prawie nigdy nie robię tego w ten sposób. Najczęściej używam debuggera przy okazji uruchamiania testów. Po znalezieniu problemu piszę padający test i wtedy jeżeli mam problem z poprawieniem kodu, uciekam się do użycia debuggera.

Kolejny dość ciekawy przypadek, przy którym może się przydać debugger, to sprawdzenie co właściwie robi jakaś metoda z biblioteki, której używamy. Czasami kod zewnętrznych bibliotek nie jest zbyt dobry i wtedy szybko kapituluję, ale bardzo często już na samym początku sprawdzane są różnego rodzaju opcje, co daje dość dużą wiedzę o tym co można do niej przekazać. Jest to też bardzo przydatne przy rozszerzaniu jakiegoś API. Railsy 3 mają na przykład bardzo fajne API w kontrolerach i jeżeli wiemy co tam się dzieje, to można stosunkowo łatwo rozszerzyć dany kontroler. Przydaje się więc możliwość prześledzenia co właściwie dzieje się np. po wykonaniu metody render

Ostatnią rzeczą, przy której często używam debuggera, jest prototypowanie i wszelkiego rodzaju "szybkie" skrypty. Przypuśćmy na przykład, że chcemy sparsować jakąś stronę w nokogiri i wyciągnąć z niej jakieś informacje. Najczęściej bardzo przydaje się przy takich zadaniach interaktywna konsola, w której możemy wypróbować wyciąganie różnych elementów. Problem w tym, że jeżeli zaczniemy od irba, to musimy tam przekleić część używanego skryptu, który otwiera stronę, tworzy dokument nokogiri i ewentualnie inne kawałki, które są nam potrzebne. Z kolei metoda debugowania polegająca na wyświetlaniu wszystkiego na ekran jest dość uciążliwa, szczególnie po dwudziestym wykonaniu tego samego skryptu. Debugger łączy zalety obu podejść. Możemy skorzystać z przygotowanego kodu i zacząć w miejscu, w którym wszystko jest już ustawione i w tym samym czasie użyć interaktywnej konsoli.

Jak używać debuggera?

Na początku musimy debugger załadować, tzn. dodajć linijkę require 'ruby-debug' gdzieś przed miejscem, które chcemy sprawdzić. Następnie w dowolnym miejscu w kodzie możemy wstawić metodę debugger. Po uruchomieniu programu, w momencie kiedy interpreter dojdzie do tego miejsca, uruchomiona zostanie konsola, w której możemy sprawdzać aktualny stan procesu i poruszać się wykonując kolejne linijki kodu.

Przed rozpoczęciem pracy polecam stworzyć plik ~/.rdebugrc, w którym można umieścić domyślny config, ja używam:

set autolist # automatyczne wyświetlenie kodu po każdej komendzie
set autoeval # automatyczne wykonanie wpisanego kodu rubiego,
             # bez tego można używać tylko metody `p` i jako
             # argument podawać kod rubiego

Jeżeli używasz rubiego w wersji 1.9.3, to na końcu tego posta są instrukcje uruchomić ruby-debug pod tą wersją.

Najczęściej używane komendy

Komendy mają z reguły skrócone wersje, dlatego będę tutaj używał wersji skróconych, a rozszerzenie podawał w nawiasie kwadratowym, np. n[ext]. Jeżeli dana komenda przyjmuje jakieś argumenty, to będą one umieszczone po nazwie metody, nawias kwadratowy oznacza, że są opcjonalne.

n[ext] — wykonanie bieżącej linii przechodząc do następnej, bez wchodzenia głębiej
s[tep] — wejście w metodę znajdującą się w bieżącej linii. Nie jest to zawsze możliwe, gdyż nie możemy zbadać wnętrza metod biblioteki standardowej napisanych w C.
c[continue] [nnn] — wznów wykonywanie programu aż do jego końca, napotkania breakpointa albo dojścia do linii nnn
b[reak] — ustawienie breakpointa (tzn. punktu, w którym wykonanie programu zostanie przerwane po wykonaniu instrukcji continue), break może również przyjmować różne argumenty:
- b[reak] [file:]line [if expr] — możemy jako argument podać linię, w której ma się ustawić breakpoint, domyślnie dotyczy to aktualnie wykonywanego pliku, ale można też użyć innego, np.: break other_file.rb:12. Można również podać opcjonalny warunek, np. break 12 if i == 1
- b[reak] class(.|#)method [if expr] — zatrzymanie na wykonaniu wybranej metody na wybranej klasie (wtedy używamy kropki, np. Thread.current) lub instancji (wtedy używamy #, np. Foo#foo)
info — wyświetla różnego rodzaju informacje, najczęściej używane jest do wyświetlania breakpointów: info b
d[elete][ nnn ] — usuwa wskazany breakpoint (jeżeli jest podany numer nnn) lub wszystkie jeżeli wywołane bez żadnych argumentów
backtrace — nazwa mówi sama za siebie ;)

Pełna lista komend jest dostępna po wykonaniu help, dokładniejszy opis każdej metody jest dostępny po wywołaniu help nazwa-instrukcji

To by było na tyle jeżeli chodzi o teorię, teraz przejdźmy do praktyki. Ze względu na to, że opisywanie tego jest lekko uciążliwe i pewnie średnio czytelne, wreszcie miałem okazję, żeby nagrać screencasta. Przejdę w nim przez kilka podstawowych przypadków, które napotkamy przy debugowaniu. Jeżeli będę miał trochę wolnego czasu, to dorzucę jeszcze drugą część, w której pokażę kilka scenariuszy wymienionych powyżej.

Ruby 1.9.3

Niestety gemy, które są wymagane do działania ruby-debug nie są cały czas publicznie wypuszczone, więc nie możemy ich prosto wylistować w Gemfile. Dlatego hostuję mały serwer rubygems, na którym je umieściłem. Jeżeli używasz rubiego w wersji 1.9.3, to używając bundlera można dopisać do Gemfile taki kod:

# source dla rubygems też powinno zostać
source 'http://gems.developers.stoliczku.pl'

group :development, :test do
  gem 'linecache19', '0.5.13'
  gem 'ruby-debug-base19', '0.11.26'
  gem 'ruby-debug19', :require => 'ruby-debug'
end

Dodakowo, jeżeli używamy RVM, to trzeba podać bundlerowi ścieżkę do źródeł:

bundle config build.linecache19 --with-ruby-include="${MY_RUBY_HOME/rubies/src}"
bundle config build.ruby-debug-base19 --with-ruby-include="${MY_RUBY_HOME/rubies/src}"

Trochę tego niestety jest, ale po wykonaniu tych kroków wszystko działa bardzo dobrze.

Mountable engines

2010-09-09T00:00:00-07:00

Jak prawdopodobnie niektórzy wiedzą, podczas wakacji pracowałem nad projektem “Rails mountable apps” w ramach Ruby Summer of Code. Projekt zakładał umożliwienie montowania aplikacji napisanych w Railsach w innych aplikacjach Railsowych. W tym momencie nie jest to jeszcze niestety możliwe, ale istnieją już solidne podwaliny w postaci “mountable engines”. Wspólnie z osobami z rails core team zdecydowaliśmy, że najlepiej będzie na razie przetestować w boju montowalne engine’y i zobaczyć w jaki sposób programiści ich używają, a później popracować na montowalnymi aplikacjami.

Czym są montowalne engine’y? Po co właściwie przez większą część wakacji siedziałem przy kodzie railsów skoro engine’y już istnieją w railsach 2.x i stosunkowo łatwo można napisać plugin z kontrolerami, modelami i widokami? Implementacja engine’ów w railsach 2.x ma kilka sporych wad. Pierwszą z nich jest zarządzanie routesami. Użytkownik nie ma żadnego wyboru w kwestii tego pod jakim urlem engine będzie się znajdował. Jeżeli twórca engine’u użyje routesów, to jedynym prostym sposobem na zmianę zachowania jest sforkowanie i ręczna zmiana kodu. Następnym problemem jest enkapsulacja. Kontrolery w obecnej wersji engine’ów zachowują się tak, jakby po prostu przekopiować je ręcznie do aplikacji. Oznacza to, że każdy kontroler dostaje automatycznie wszystkie helpery z aplikacji. W niektórych przypadkach może to być pożądane zachowanie, ale przy użyciu engine’ów napisanych przez innych, wiąże się to z ryzykiem kolizji nazw. Kolejne ograniczenie to rack middlewares. Nie można w prosty sposób dodać middleware’ów, które będą podpięte tylko do engine’u. Jedyny sposób to ręczne sprawdzanie ścieżki (np. env["PATH_INFO"] =~ /^\/tolk/, niezbyt wygodne). W railsach 3.0 można co prawda używać aplikacji racka w kontrolerach, ale jest to dość ograniczone, tzn. wpinamy się już po przejściu przez router i cały middleware stack. Ostatnią rzeczą, o której chciałbym wspomnieć, jest wygoda. Ze względu na konflikty nazw, najbezpieczniej jest umieścić wszystkie modele, kontrolery i helpery w module. Pociąga to za sobą jednak kilka niedogodności. Np. w tym momencie wszystkie helpery generujące urle trzeba prefixować, np. blog_posts_path. Tak samo jest z modelami, domyślna nazwa wygenerowana przez ActiveModel::Naming, to blog_post dla klasy Blog::Post.

Podczas pracy w RSoC próbowałem poprawić te problemy. W efekcie zaszło dość dużo zmian w zachowaniu engine’ów:

engine jest teraz aplikacją rack
posiada własny middleware stack
posiada własne routesy
pliki z katalogu public mogą być serwowane z użyciem ActionDispatch::Static
może posiadać swoje własne pluginy
w prosty sposób można umieścić modele i kontrolery w module

Co się zmieniło?

Izolowany lub współdzielony engine

Do tej pory pliki z katalogu ‘app’, znajdującego się w katalogu z engine’em, zachowywały się mniej więcej tak, jakby wkleić je do katalogu app w aplikacji. Skutek tego był taki, że dostawały wszystkie helpery (w tym także helpery do routesów) z aplikacji. Dla niektórych engine’ów jest to pożądane zachowanie (np. Devise), ale istnieje wiele przypadków, w których nie działa to zbyt dobrze. W przypadku użycia jakiegoś dużego engine’u, takiego jak np. forum, istnieje duża szansa wystąpienia konfliktów (np. takie same nazwy metod w helperach). Dlatego od railsów 3.1 wprowadzona zostanie możliwość oznaczenia, że Engine jest izolowany używając metody isolate_namespace:

module Blog
  class Engine < ::Rails::Engine
    isolate_namespace Blog
  end
end

Przy takiej konfiguracji kontrolery znajdujące się w module Blog, dostaną tylko i wyłącznie helpery i routesy znajdujące się w tym samym namespace.

Montowanie engine’u

Engine można zamontować w aplikacji tak jak każdą aplikację Rack, używając metody mount:

mount Blog::Engine => "/blog", :as => "blog"

Przy takiej definicji engine będzie dostępny w /blog.

Routes

Z powodu tego, że Engine może teraz posiadać swoje własne routes’y, czasami zajdzie potrzeba odwołania się do routesów engine’u z aplikacji i na odwrót. Dlatego stworzone zostały helpery, ktore to umożliwiają. Helper main_app służy do odwołania się do routesów aplikacji, a helpery dla zamontowanych engine’ów zależą od opcji :as użytej w powyższym przykładzie. Np. dla powyższego przykładu, helper do engine’u Blog::Engine będzie nazywał się blog. Dzięki temu można napisać np.:

blog.posts_path
blog.root_path

main_app.login_path

Oczywiście takie helpery muszą być użyte tylko przy odwoływaniu się do innych routesów, np. kiedy chcemy wygenerować ścieżkę do routesów bloga z kontrolera aplikacji.

Namespacing

Żeby uniknąć konfliktów, montowalny engine musi być zamknięty w namespace. W normalnych warunkach skutkuje to tym, że wszędzie trzeba dodawać prefix (np. nazwa dla modelu Blog::Post, to w normalnych warunkach blog_post, route to blog_posts_path itp.

Tego typu prefixy w zwykłym enginie są używane w celu uniknięcia konfliktów. W izolowanym enginie najczęściej nie ma takiego problemu. Np. nie opłaca się w środku engine’u pisać blog_posts_path zamiast posts_path. Tak samo podczas wysyłania parametrów z formularza, nie opłaca się używać params[:blog_post] zamiast params[:post]. Engine oznaczony jako izolowany pozwala na ominięcie tych prefixów w większości miejsc.

Migracje

Jeżeli używacie w swojej aplikacji ActiveRecorda, to przydadzą się też migracje. Obecne podejście do migracji engine’ów, to kopiowanie migracji do katalogu aplikacji z przepisaniem timestampów. Dla przykładu mamy w enginie Blog::Engine migrację 20091212_create_posts.rb. Po wykonaniu w dniu 2010-10-10 komendy:

rake railties:copy_migrations

zostanie ona przekopiowana do katalogu aplikacji z nazwą 20101010_create_posts.blog.rb. Wybraliśmy ten sposób z kilku powodów:

przed wykonaniem migracji warto na nią spojrzeć, co po przekopiowaniu do katalogu aplikacji jest dużo łatwiejsze
tego typu format jest zgodny z dotychczasowym, więc nie trzeba było zmieniać tabeli schema_migrations
dzięki przepisywaniu timestampów nie wystąpi sytuacja, w której po przekopiowaniu migracji, będą one wykonywane przed migracjami aplikacji (ma to znaczenie kiedy w czasie rozwijania aplikacji dodamy jakieś pole do tabeli z engine’u)

Pliki statyczne

Ostatni problem jaki trzeba było rozwiązać, to serwowanie statycznych plików. Są na to obecnie 2 sposoby:

utworzenie symlinków do katalogów public w enginach, służy do tego task rake railties:create_symlinks
wykorzystanie ActionDispatch::Static (middleware, który serwuje pliki statyczne)

Tutorial

Najłatwiej pokazać wszystkie zmiany w praktyce, więc pokuszę się o napisanie prostego engine’u. Do wygenerowania tego engine’u użyjemy enginex napisanego przez José Valima. Niech nie zmyli was nazwa. Enginex został co prawda stworzony w celu prostego generowania engine’ów, ale z powodzeniem można go używać do wygenerowania szkieletu dla dowolnego gema, który będzie miał za zadanie działać z railsami 3. Na początek zainsalujmy enginex:

gem install enginex

Po wykonaniu komendy enginex --help pokażą się dostępne opcje. W chwili obecnej można ustawić jedynie test framework (rspec lub test unit). Zacznijmy z domyślnym test unit:

enginex blog

Enginex powinien stworzyć w tym momencie katalog blog, w którym będą znajdować się pliki z reguły pojawiające się w gemach (lib, test, README itp) oraz coś nowego – aplikacja railsów w katalogu test/dummy. Po co nam aplikacja railsów? Ze względu na to, że engine (czy też inny rodzaj gemu) będzie pracował z railsami i najłatwiej testować go w realnym środowisku railsów.

Pierwsze co trzeba będzie zmienić, to plik Gemfile. Obecna wersja enginex zakłada, że użyte będą railsy 3.0. Całkiem słuszne założenie dla większości projektów, ale żeby korzystać z dobrodziejstw najnowszej wersji engine’ów, trzeba będzie użyć wersji z githuba. Co więcej, trzeba będzie użyć wersji z mojego forka railsów na githubie. Co prawda większość rzeczy, nad którymi pracowałem, jest już w oficjalnym repozytorium railsów, ale cały czas poprawiam różne rzeczy i ze względu na to, że nie mam możliwości commitowania, trzeba czasami poczekać trochę na akceptację i dorzucenie do oficjalnej wersji.

Dlatego zmieniam Gemfile, żeby wyglądało w ten sposób (przy okazji dorzuciłem też factory_girl_rails, przyda się później):

source "http://rubygems.org"

gem "rails", :git => "git://github.com/drogus/rails.git", :branch => "engines"
gem "arel", :git => "git://github.com/rails/arel.git"

gem "factory_girl"
gem "capybara", ">= 0.3.9"
gem "sqlite3-ruby", :require => "sqlite3"

if RUBY_VERSION < '1.9'
  gem "ruby-debug", ">= 0.10.3"
end

Teraz tylko bundle install w konsoli i można zacząć pracować. Dla pewności, że środowisko się poprawnie wczytuje, można jeszcze odpalić testy: rake test

Jeżeli testy przechodzą, to można się zabrać za pisanie kodu. Od czego zacząć? Od testów oczywiście ;-) Po przejrzeniu katalogu test, łatwo zauważyć, że znajduje się tam katalog integration. Wygenerowane przez enginex testy korzystają z Capybary, dzięki czemu można łatwo pisać testy integracyjne. Zacznijmy od wyświetlania postów na blogu. Stwórzmy plik test/integration/posts_integration_test.rb:

require 'test_helper'

class PostsIntegrationTest < ActiveSupport::IntegrationCase
  test "I can see blog posts on blog's root page" do
    Factory.create(:post, :title => "Awesome!", :body => "All work and no fun makes Jack a dull boy")

    visit blog.root_path
    assert page.has_content?("Awesome!")
    assert page.has_content?("All work and no fun makes Jack a dull boy")
  end
end

Po uruhomieniu rake test zobaczymy: ArgumentError: No such factory: post. Brakuje nam wpisu post w factories. Dodajmy go więc:

# test/factories.rb

Factory.define :post, :class => "Blog::Post" do |f|
  f.title "My post"
  f.body "It's just a post, man..."
end

Do pliku test/test_helper.rb dodajemy również require "factories".

Tym razem po uruchomieniu testów, błąd powinien wyglądać mniej więcej tak: NameError: uninitialized constant Blog::Post. Nic dziwnego, nie ma jeszcze w kodzie żadnego modelu. Model jest oczywiście namespace’owany i dlatego używamy Blog::Post zamiast normalnego Post. Nie pozostaje nic innego jak dodać taki model:

# app/models/blog/post.rb
module Blog
  class Post < ::ActiveRecord::Base
  end
end

Musimy dodać także migrację i sprawić, żeby była uruchamiana przy każdym odpaleniu testów (między innymi przez takie problemy uważam, że mongodb, to przyszłość modularnych aplikacji ;-). Powstają tutaj dwa problemy. Pierwszym z nich są generatory. W tej chwili niestety generatory nie działają w katalogu engine’u. Drugi problem jest związany z uruchamianiem migracji, nie ma obecnie żadnego mechanizmu, który automatyzuje wykonywanie migracji dla engine’u w testach. Ale co to dla nas?

Stwórzmy migrację:

# db/migrate/20100631120813_create_blog_posts.rb
class CreateBlogPosts < ActiveRecord::Migration
  def self.up
    create_table :blog_posts do |t|
      t.string :title
      t.text :body

      t.timestamps
    end
  end

  def self.down
    drop_table :blog_posts
  end
end

Teraz wystarczy stworzyć plik test_helper i wkleić pod komentarzem “#Run any available migrations” poniższy kod:

# Run any available migrations
FileUtils.rm(Dir[File.expand_path("../dummy/db/test.sqlite3", __FILE__)])
FileUtils.rm(Dir[File.expand_path("../dummy/db/migrate/*.blog.rb", __FILE__)])
FileUtils.mkdir_p(File.expand_path("../dummy/db/migrate/", __FILE__))
ActiveRecord::Migration.copy File.expand_path("../dummy/db/migrate/", __FILE__), { :blog => File.expand_path("../../db/migrate/", __FILE__) }
ActiveRecord::Migrator.migrate File.expand_path("../dummy/db/migrate/", __FILE__)

Kod ten usuwa wszystkie wcześniej skopiowane migracje i bazę sqlite3, po czym kopiuje aktualne migracje z katalogu db/migrate i je uruchamia.

Ok… Uruchamiany testy i: NameError: uninitialized constant Blog::Post. Pomimo tego, że model jest już stworzony, w testach dalej go nie widać. Dlaczego tak się dzieje? Nigdzie nie powiedzieliśmy, że aplikacja ma wczytać nasz Engine… a właściwie nawet nie mamy jeszcze engine’u! Po sprawdzeniu pliku lib/blog.rb można zauważyć, że jest tam jedynie:

module Blog
end

Enginex nie robi żadnych założeń co do tego jakiego rodzaju gem chcemy zrobić. Trzeba to skorygować, w pliku lib/blog/engine.rb wstawmy kod engine’u:

module Blog
  class Engine < ::Rails::Engine
    namespace Blog
  end
end

a w lib/blog.rb załadujmy powyższy kod:

require 'blog/engine'

Pojawia się tutaj opisywana wcześniej metoda namespace, która sprawia, że Engine jest izolowany.

Tym razem po uruchomieniu testów dostaniemy taki błąd: NameError: undefined local variable or method `blog' for #<PostsIntegrationTest:0x000001041136e0>. Chodzi o linijkę blog.root_path w teście. Brakuje nam helperow do routesów zamontowanych engine’ów. W przyszłości takie helpery będą prawdopododbnie automatycznie dołączane do testów, ale w tym momencie niestety trzeba będzie zrobić to samemu. W pliku test/support/integration_case.rb w ciele klasy ActiveSuppoer::IntegrationCase należy wkleić:

include Rails.application.routes.mounted_helpers

W tym momencie helpery powinny już być dostępne, ale po uruchomieniu testów dalej dostaniemy ten sam błąd. Dlaczego? Jak już pisałem są to helpery do wszystkich zamontowanych engine’ów. A tak się składa, że Blog::Engine nie jest jeszcze nigdzie zamontowany. Poprawmy to montując engine w aplikacji w pliku test/dummy/config/routes.rb:

mount Blog::Engine => "/blog", :as => "blog"

Po uruchomieniu testów powyższy błąd powinien zniknąć, ale za to dostajemy kolejny związany z routesami: NoMethodError: undefined method `root_path' for #<ActionDispatch::Routing::RoutesProxy:0x00000101e9bd10>. Wynika to z faktu, że nie zdefiniowaliśmy jeszcze żadnych routesów w enginie. Aby to zrobić wystarczy wkleić taki oto kod w pliku config/routes.rb:

Blog::Engine.routes.draw do
  root :to => "posts#index"
end

Routesy powinny już działać poprawnie, ale testy podpowiadają nam, że brakuje kontrolera: ActionController::RoutingError: uninitialized constant Blog::PostsController. Kontroler powinien wyglądać mniej więcej tak:

module Blog
  class PostsController < ActionController::Base
    def index
      @posts = Post.all
    end
  end
end

i znajdować się w pliku app/controllers/blog/posts_controller.rb. Ciekawe w tym kodzie jest to, że nie musimy używać Blog::Post, wystarczy samo Post, ponieważ już jesteśmy w odpowiednim namespace. Dlatego właśnie używam dłuższej formy: module Foo; class Bar; end; end. Przy zastosowaniu skróconego zapisu nie dałoby się tak zrobić:

class Blog::PostsController < ActionController::Base
  def index
    @posts = Post.all #=> ArgumentError: Blog is not missing constant Post!
  end
end

A wracając do samego engine’u… Jak pewnie niektórzy się domyślą, tym razem testy będą krzyczeć o braku template’u. Stwórzmy więc app/views/blog/posts/index.html.erb, a w nim wyświetlmy pobrane w kontrolerze posty:

<h2>Posts</h2>

<% @posts.each do |post| %>
  <h3><%= post.title %></h3>
  <div class="post">
    <%= post.body %>
  </div>
<% end %>

W tym momencie testy powinny przechodzić! Aplikacja już działa, ale przydałby się jakiś layout. Do pliku app/views/layouts/blog.html.erb skopiujcie poniższy kod:

<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <title>Blog</title>
</head>
    <header>
      <h1>Blog</h1>
    </header>

    <div id="main">
      <%= yield %>
    </div>

    <footer>
    </footer>
  </div>
</body>
</html>

Teraz trzeba ten layout ustawić w kontrolerze. Z reguły robi się to w ApplicationController i żeby pozostać DRY, w enginie też można tak zrobić (z tą różnicą, że tutaj będzie to Blog::ApplicationController, który będzie wyglądał tak:

module Blog
  class ApplicationController < ActionController::Base
    layout "blog"
  end
end
end

Wystarczy jeszcze tylko zmienić Blog::PostsController, żeby dziedziczył z ApplicationController i layout powinien poprawnie się wyświetlać:

class PostsController < ApplicationController

Ok, super, ale nie można przecież rozwijać aplikacji opierając się tylko na testach. Tutaj również możemy skorzystać z testowej aplikacji. Wejdźcie do katalogu test/dummy, wykonajcie migracje rake db:migrate, włączcie konsolę script/rails c, a w konsoli stwórzcie jakieś posty:

Blog::Post.create(:title => "First post", :body => "This is awesome!")
Blog::Post.create(:title => "Missed missy", :body => "Missy needs your help... :(")

Teraz można już włączyć serwer, zobaczyć jak to wygląda i dodać style. Wystarczy uruchomić serwer (script/rails s) i wejść na http://localhost:3000/blog. Powinniście zobaczyć tam dodane przed chwilą posty. W layoucie blog.html.erb można teraz wstawić link do cssów:

  <%= stylesheet_link_tag "style" %>

a w pliku public/stylesheets/style.css (w katalogu engine’u, nie aplikacji) na przykład:

header h1 {
  color: #A80000;
}

Po uruchomieniu serwera tytuł bloga powinien zmienić kolor na czerwony. Serwowanie plików statycznych działa bez wprowadzania żadnych zmian, ponieważ w trybie development domyślnie uruchamiany jest ActionDispatch::Static. W środowisku production, trzeba ustawić config.serve_static_assets na true, lub wykonać rake railties:create_symlinks w celu stworzenia symlinków do katalogów public w engine’ach.

Na tym chciałbym zakończyć ten tutorial. W razie czego aplikację umieściłem na W kolejnych odsłonach napiszę trochę więcej o tym jak dalej obchodzić się z tego typu engine’ami. Dla podsumowania, po przeczytaniu tej notki powinniście wiedzieć jakie są różnice pomiędzy starszą wersją engine’ów, a tym co obecnie siedzi w rails/master oraz umieć stworzyć prosty montowalny engine.

Sprostowanie

2010-05-16T00:00:00-07:00

Ze względu na dziwne właściwości google readera w ostatnich godzinach zrobiło się niezłe zamieszanie z postami w RSSie. Zmieniłem adres bloga i naiwnie pomyślałem, że jeżeli podmienię w feedburnerze adres do starego feeda, to google reader zupdate’uje po prostu treść. Nic bardziej mylnego. Okazuje się, że google reader nie kasuje z cache’a żadnych postów. Dodatkowo nic go nie obchodzą daty, które są ustawione w RSSie, posty układa tak jak mu się podoba, a nie tak jak mu mówi atrybut ‘published’ w XMLu. Z tego powodu jakieś stare posty sprzed 3 lat pojawiły się na samej górze w czytniku. Pech sprawił, że wśród kilkudziesięciu postów na drugim miejscu był post sprzed 3 lat, w którym pisałem o rzuceniu pracy i studiów. Pragnę wyjaśnić, że jest to już daleka przeszłość i moje obecne studia i praca mają się niezwykle dobrze. Przepraszam za zamieszanie, od teraz będę miał na uwadze, że cache google readera jest nieugięty i choćbyście nawet bardzo chcieli, to nie uda się usunąć postów, które się w nim znajdują.

Jeżeli ktoś natrafi na ten problem, to od razu mogę podrzucić rozwiązanie. W googlu można znaleźć w ciągu kilku sekund przynajmniej kilkanaście tematów na forach i postów dotyczących tego problemu. W supporcie googla w jednym z tematów tego typu odpowiada nawet pracownik googla, który twierdzi, że jeżeli post już dodał się do cache’u, to “niezwykle trudno go stamtąd usunąć”. Prawdopodobnie jestem za cienki w łokciach, żeby się wypowiadać negatywnie o inżynierach googla, ale trochę mnie dziwi fakt, że bez problemu można w google web developer tools usunąć cache całej strony, która ma kilkadziesiąt tysięcy zaindeksowanych plików, ale nie można co jakiś czas odświeżyć cache’a RSSów. Przechodząc do samego rozwiązania. Posty nie mogą zostać usunięte, ale za to można zmienić ich treść. Dlatego jeżeli zachowane zostanie id posta, to google weźmie to za update. W ten sposób można podmienić zawartość niechcianych postów na coś w stylu “treść usunięta”. Życzę powodzenia w nierównej walce z cache’em googla!

Zmiana adresu

2010-05-16T00:00:00-07:00

Od dłuższego czasu nie pisałem nic na blogu. Było to częściowo spowodowane tym, że chciałem zmienić jego adres i połączyć z drugim blogiem (polski blog miał adres blog.drogomir.com, angielski drogomir.com/blog, kto w ogóle wymyśla taką dziwną konfigurację? nawet ja się najczęściej gubiłem pod którym adresem jest który blog). Ilekroć siadałem do edytora, żeby napisać coś sensownego, do głowy przychodziła mi myśl: przenieś w końcu te blogi! Zamykałem edytor, otwierałem internety, żeby zobaczyć na co zmigrować oba blogi i… po 10 minutach dawałem sobie spokój. W ostatnich dniach zebrałem się wreszcie, żeby przenieść oba blogi na nowy adres. Jak łatwo możecie zauważyć nowy adres to piotrsarnacki.com. Posty w języku polskim są dostępne pod adresem piotrsarnacki.com/pl. Nowe adresy dla RSSów to odpowiednio:

feeds.feedburner.com/piotrsarnacki-all – wszystkie posty
feeds.feedburner.com/piotrsarnacki – posty angielskie
feeds.feedburner.com/piotrsarnacki-pl – posty polskie

Posty powinny być też dostępne pod obecnym adresem RSS, ale zachęcam do zmiany na nowy adres :)

Od strony technicznej: blog jest hostowany na githubie z pomocą jekylla. Na początku miałem wątpliwości czy będzie to dobry pomysł. Jekyll jest niezwykle prosty w użyciu i ma przy tym spore możliwości, ale przy okazji traci się trochę elastyczności na rzecz wygenerowanego statycznego HTMLa. Tylko… tak naprawdę, po co mi coś więcej? Całego bloga trzymam w repozytorium gita, więc łatwo jest śledzić historię zmian. Mam darmowy hosting na githubie, więc nie muszę się już martwić o utrzymanie dla blogów jakiegokolwiek serwera. Posty mogę łatwo dodawać i edytować będąc offline. Wspaniała sprawa. :)

Layout bloga jest w tym momencie skopiowany ze strony Toma Preston-Werner (tak, to ten od githuba ;-) ze względu na to, że wszystko oprócz postów jest na licencji MIT, a dzięki temu mogłem praktycznie w 10 minut postawić bloga (więcej czasu zajęło przeniesienie postów z typo i mephisto, ale dzięki skryptom przygotowanym specjalnie dla jekylla, także ta operacja była prawie bezbolesna). Część postów poszło do kosza ze wzgłedu na ich przedawnienie (przez te kilka lat zmieniło się w railsach całkiem dużo i nikogo już pewnie nie obchodzi, że właśnie wyszły railsy w wersji 1.2-rc2), część postaram się oznaczyć jako deprecated (swoją drogą zrobienie prostego mechanizmu do oznaczania w ten sposób postów jest w jekyllu banalnie proste, skrobnę później o tym posta).

Na koniec muszę się jeszcze pochwalić. Prawdodpodobnie większość z was wie o tegorocznym Ruby Summer of Code. Dla tych którzy nie wiedzą: w tym roku żadne projekty związane bezpośrednio z Ruby nie dostały się na Google Summer of Code, więc społeczność (mocno wspierana przez Engine Yard, który z tego co pamiętam jest inicjatorem pomysłu) zorganizowała sobie własne Summer of Code. W 3 dni zebrano 100 tysięcy dolarów, co pozwoli sfinansować 20 projektów. Wśród owych 20 projektów znalazło się miejsce dla 2 Polaków:

Marcin Raczkowski – będzie pracował nad Identity Map dla ActiveRecord
Piotr Sarnacki (czyli skromny autor tego oto blogusia ;-) – będę pracował nad mountable apps i panelem admin do Railsów 3 (w zasadzie sytuacja jest trochę bardziej skomplikowana, ponieważ moje zgłoszenia zostały połączone ze zgłoszeniami Bogdana Gazy i pracujemy w jednym projekcie, przy czym ja jestem bardziej odpowiedzialny za część dotyczącą mountable apps, a Bogdan za rails-admin)

Pracę nad projektem zacznę prawdopodobnie w połowie czerwca i na blogu postaram się informować na bieżąco o postępach.

Google chce przyśpieszyć internet

2009-06-26T00:00:00-07:00

Nie od dziś wiadomo, że prędkość ładowania strony ma wpływ na akcje użytkowników. Badania prowadzone miedzy innymi przez Yahoo, Google i Amazon wskazały, że zmniejszenie czasu ładowania strony ma bezpośredni wpływ na ilość akcji wykonanych przez użytkowników (wyszukiwań lub w wypadku Amazona zakupionych przedmiotów).

Google odpalił niedawno stronę, na której zachęca i uczy jak przyśpieszyć działanie naszych stron i serwisów

Dodatkowo Google wypuścił narzędzie Page Speed, które jest rozszerzeniem do Firebuga i podobnie jak YSlow pomaga zbadać stronę pod kątem prędkości ładowania się poszczególnych komponentów. Oba te narzędzia dostarczają od razu praktycznych porad i opisów pomagających zrozumieć jak zoptymalizować stronę. Dla mnie są to niezbędne narzędzia przy pracy z serwisami internetowymi. Do tej pory używałem głównie YSlow, ale przy następnych optymalizacjach na pewno skorzystam z Page Speed.

Jeżeli jeszcze nie znacie tych narzędzi, gorąco polecam zapoznanie się z nimi.

YUI 3 beta

2009-06-25T00:00:00-07:00

We wczorajszym poście na blogu YUI ogłoszono wersję beta YUI3.

YUI (Yahoo User Interface) jest frameworkiem javascript rozwijanym przez YAHOO, który dostarcza nie tylko niskopoziomowe funkcje pomagające przy pisaniu kodu javascript, ale też zestaw komponentów (takich jak różnego rodzaju okienka dialog, color picker, czy nawet bardzo dobry edytor WYSIWYG). YUI jest dojrzałą biblioteką używaną na stronach YAHOO, co zapewnia bardzo dobrą jakość. Sam team YUI to jedni z najlepszych specjalistów od frontendu – zachęcam do czytania wpisów na ich blogu

To co najbardziej przekonywało mnie do używania YUI, to fakt dostarczenia całego zestawu narzędzi do budowania interfejsów użytkownika w javascripcie. W przypadku np. jQuery lekko może denerwować bardzo duże rozstrzelenie poszczególnych bibliotek. Są oczywiście takie projekty jak jqueryUI, ale większość pluginów trzeba ściągnąć z innych źródeł, a ich kod często pozostawia wiele do życzenia. W przypadku YUI mamy zwarty zestaw komponentów, łatwy do rozszerzania i rozwijany przez specjalistów w celu wykorzystania na stronach odwiedzanych codziennie przez miliony internautów.

Z drugiej strony to co było banalne w jQuery często było ciężkie do uzyskania w YUI. A jak wszyscy wiedzą jeżeli chodzi o zabawę z DOM, animacjami i ajaxem z jQuery jest ciężko wygrać. Dlatego gdy używałem komponentów YUI w jednym z projektów, w którym przy okazji używałem jQuery, to do manipulacji elementów DOM używałem jQuery, a z YUI wybierałem tylko komponenty.

Wersja trzecia YUI może to zmienić. Zespół z Yahoo postanowił przepisać bibliotekę zupełnie od nowa z naciskiem na lekkość i szybkość. Najważniejsze zmiany

zmienione API do manipulacji DOM, czyli “jQueryzacja” – łańcuchy komend, proste funkcje typu addClass, remove, append itp.
ułatwiona praca z eventami
modularyzacja biblioteki

Najbardziej obiecująco wygląda ostatni punkt. Do tej pory poszczególne komponenty nie były modularne, co prowadziło do powtarzającego się kodu w różnych komponentach. Dodatkowo jeżeli ktoś chciał stworzyć Tooltip dziedziczący po Overlay, to musiał wykorzystać wszystkie elementy, które Overlay zawiera. Jest to oczywiście zbędne wykorzystywanie pamięci i Tooltip, który jest obecnie dostępny w YUI właśnie z tego powodu nie jest najlepszą możliwą implementacją.

W YUI3 poszczególne funkcjonalności są rozbite do modułów. Dlatego, żeby zbudować wspomniany wyżej tooltip nie trzeba dziedziczyć po Overlay, tylko zmiksować (czy to nie brzmi znajomo?) na przykład: moduł pozycjonowania i moduł animacji. Dodatkowo można wmiksować poszczególne moduły nie tylko do klas, ale także instancji poszczególnych obiektów. Jeżeli będzie to rzeczywiście działało tak fajnie jak mówią programiści z YUI (polecam obejrzeć video ze zlinkowanego wcześniej posta), to YUI3 na pewno zagości w moich projektach.

To co najbardziej denerwuje mnie obecnie w różnego rodzaju bibliotekach do jQuery czy prototype, to całkowite oderwanie poszczególnych bibliotek od siebie. Używam na przykład jqueryUI i żeby użyć tooltipa, muszę ściągnąć zupełnie inną bibliotekę, która jest napisana zupełnie inaczej i nie dzieli żadnego kodu z innymi bibliotekami (tutaj też wychodzi swoboda javascriptu, jeżeli ktoś próbował porównywać implementacje różnych bibliotek, to na pewno wie na ile różnych sposobów można zaimplementować te same funkcje). Jeszcze gorzej jest gdy trzeba napisać własne komponenty – lekkość jQuery i brak oficjalnych bibliotek pomagających w takich wypadkach jest dość dużą przeszkodą.

W tym momencie YUI team zachęca programistów do używania YUI3 w nowych projektach, szczególnie tych, które nie planują wykorzystywać dużej ilości widgetów obecnych w YUI2. Oficjalna wersja ma być dostępna w 3 kwartale tego roku. Rozwój można biblioteki śledzić tutaj

Co nowego w Rails3?

2009-05-03T00:00:00-07:00

Ponad 4 miesiące temu światem Ruby’iego zatrzęsła wiadomość o połączeniu się 2 popularnych frameworków – Ruby on Rails i Merba. Dzisiaj, tylko kilka dni dzieli nas od ujrzenia pierwszych aplikacji, które będą napisane w Rails 3. Carl Lerche (twórca między innymi routera do merba) oraz Yehuda Katz na tegorocznym RailsConf będą mówić o Rails3 i mountable apps.

Na stabilną wersję będzie trzeba jeszcze trochę poczekać, ale trzymam kciuki, żeby na RailsConf rzeczywiście udało im się pokazać działającą aplikację.

W tym poście chciałbym krótko opisać to co ma się znaleźć w Rails 3. Z niemałą niecierpliwością śledzę newsy i doniesienia o nowych railsach i nie mogę się już doczekać niektórych usprawnień.

ActionORM (wcześniej ActiveORM)

Zwolennicy Merba bardzo podkreślają w swoim frameworku niezależność od konkretnych technologii. Było to reklamowane głównie jako “ORM agnosticism” czyli możliwość podpięcia do Merba jednego z wielu “ORMów” (DataMapper, ActiveRecord, Sequel) w porównaniu do Railsowej monolityczności w postaci jednego słusznego ActiveRecorda.

Jaki właściwie jest problem w używaniu innego ORMa w naszej aplikacji? Na poziomie modeli i kontrolerów nie ma to z reguły większego znaczenia. Przecież Railsów nie obchodzi czy klasa w katalogu app/models dziedziczy po ActiveRecord::Base, czy dołącza moduł: include DataMapper::Resource

Kłopot zaczyna się kiedy chce się korzystać z wielu helperów, które jako argument przyjmują obiekt ActiveRecord. Najprostszy przykład:

<% form_for @article do |f| %>
  <%= f.text_field :title %>
<% end %>

Jeżeli @article nie jest obiektem AR, to poprawność działania tej metody zależy tylko od tego czy interfejs danego ORMa tutaj używany jest taki sam. W tym akurat przypadku problemem może być sprawdzanie błędów w walidacji. Railsy domyślnie dodają wrapper do pól z błędami, więc jeżeli ORM ma inny interfejs do pobrania informacji o błędach, to metoda po prostu nie zadziała.

W tym momencie jest to w Railsach zrobione z użyciem alias_method_chain i jeżeli obiekt nie ma zaimplementowanej metody errors, to tag pozostaje niezmieniony, więc można samemu dołączyć swoją własną implementację lub dodać potrzebne metody do modelu. Jednak wszyscy chyba się zgodzą, że nie jest to najbardziej elegancki sposób.

Jeżeli chodzi o Merba, to sprawa wygląda tylko trochę lepiej niż w railsach. Jest co prawda wsparcie dla 3 najpopularniejszych ORMów, ale implementacja nie pozwala na łatwe dodanie kolejnych ORMów bez grzebania w kodzie. Jeżeli ORM, którego chcesz używać ma interfejs zgodny z DataMapperem, Sequelem lub ActiveRecordem, to wszystko jest ok, ale jeżeli jest to coś innego, to masz problem.

Odpowiedzią na to ma być ActionORM. Czym jest ActionORM? Jest to proste proxy dla obiektów. ActionORM udostępnia API takie jak ActiveRecord (dzięki temu w kodzie railsów nie będzie trzeba wiele zmieniać). W prostych słowach ActionORM ma sprawić, że obiekty innych ORMów będą wyglądały jak obiekty ActiveRecord (czyli klasyczne wykorzystanie duck typing)

Tutaj jest przykład proxy dla Datamappera

Różnice są jak widać niewielkie, ale podejrzewam, że będzie można dodać więcej metod, które się różnią pomiędzy implementacjami (oczywiście w granicach rozsądku, sprowadzanie całego interfejsu do jednego przypadku było by pozbawione sensu, chodzi o proste operacje, które każdy ORM ma rozwiązane podobnie, ale różni się API).

Rack Middleware

Railsy od jakiegoś czasu wykorzystują w pełni dobrodziejstwa Rack. Co więcej, różne części frameworka są zaimplementowane jako rack middlewares. Kontroler, router, obsługa sesji i wiele innych rzeczy to teraz po prostu kolejne middlewares (przepraszam za te anglojęzyczne wstawki, ale naprawdę nie mam pojęcia jak to ładnie przetłumaczyć). Dzięki temu i dodaniu Rails metal aplikacje są coraz bardziej modularne.

Programiści railsów dążą w tej chwili do jeszcze szerszego wykorzystania racka. Wszystko to idzie w stronę jak najłatwiejszego połączenia komponentów różnego typu. Na przykład możliwość podłączenia do routera kontrolerów railsowych, aplikacji sintatry i aplikacji merba (jako jedną aplikację oczywiście).

Optymalizacja i refaktoryzacja

Największą i najlepszą według mnie zmianą w railsach jest refaktoryzacja kodu ActionPack. Na czym ona polega? W bardzo prostych słowach: stworzony jest AbstractController, z którego dziedziczyć będą inne kontrolery, a w samym kodzie jest zastosowana dużo większa enkapsulacja. Jakie to ma znaczenie dla użytkowników railsów? Będzie istniał jeden interfejs dla wszystkich kontrolerów, dzięki czemu na przykład ActionController i ActionMailer będą mogły współdzielić funkcjonalność (żeby nie iść daleko, dopiero niedawno do mailera dodana została obsługa layoutów). Bardzo łatwe będzie też dodanie Parts znanych z merba (PartsController również dziedziczy w Merbie z AbstractControllera).

W chwili obecnej podobną funkcjonalność do Merb Parts udostępniają Rails Cells, ale nie jest to rozwiązanie idealne (implementacja jest zagmatwana, w cellach widoczne są zmienne instancji z kontrolerów i innych celli, podejrzewam, że jest to wolniejsze niż parts).

Co jeszcze? Yehuda Katz wziął się między innymi za optymalizację callbacków, czy bloku respond_to. Polecam również inne artykuły na temat refaktoryzacji na jego blogu.

Na pewno szybszy będzie też router. W chwili obecnej największym problemem jest to, że router generuje bardzo dużo metod (wszystkie metody _url i path), co w rezultacie przyczynia się do bardzo wolnego startu aplikacji. W czasach mongreli nie miało to dużego znaczenia, bo aplikacje były odpalane raz i tylko sporadycznie restartowane. Teraz kiedy na wielu serwerach zainstalowany jest modpassenger, czas startu aplikacji jest dużo ważniejszy – instancje, które nie dostają requestów przez 5 minut (domyślne ustawienie) są wyłączane dzięki czemu nie zajmują zasobów.

Nowy router można przetestować już teraz. Po więcej odsyłam na the merbist

Mountable apps

Jest to jedna z tych rzeczy, na które czekam w Railsach 3 najbardziej. Dosłownie liczę godziny do rails conf i prezentacji na ich temat (mam nadzieję, że będą nagrywane, bo niestety nie miałem wolnych kilku tysięcy złotych, żeby się pojawić osobiście na konferencji ;-).

Jakieś namiastki mountable apps są już dostępne w postaci Rails Engines i Merb Slices. Jest to jakieś rozwiązanie, ale na pewno dalekie od idealnego. Żeby skorzystać z którejś z tych opcji trzeba napisać specyficzny rodzaj aplikacji, a każde z tych rozwiązań jest w niektórych miejscach niedopracowane. Celem mountable apps będzie możliwość łatwego połączenia 2 aplikacji bez żadnych zmian w kodzie.

API dla pluginów

Jedną z rzeczy, którą wypromował Merb jest publiczne i prywatne api. Dzięki temu pisanie pluginów nie wiąże się tam z używaniem alias_method_chain i ogólnie pojętym monkey patchingiem na każdym kroku. A jeżeli czegoś nie da się zrobić używając tylko publicznego api, to jest to bug. Jest to chyba jedna z trudniejszych rzeczy w całej refaktoryzacji. Nie wiadomo dokładnie czego będą potrzebować twórcy pluginów, niektóre metody trzeba będzie dopiero stworzyć.

Ogromnym plusem takiego podejścia jest to, że twórcy frameworka nie muszą się martwić o prywatne metody, ważne żeby publiczne API się nie zmieniało. Dzięki temu pluginy napisane zgodnie z wytycznymi, czyli nie używając prywatnego API nie będą się wysypywały na każdej kolejnej wersji (co bardzo często można zaobserwować w tym momencie), a jeżeli coś się zmieni w publicznym API przy okazji większych zmian, to twórcy pluginów będą mogli się o tym łatwo dowiedzieć bez śledzenia commitów na githubie.

Podsumowanie

Jestem zdania, że połączenie merba i railsów to jedna z najlepszych rzeczy, która mogła się przytrafić programistom webowym. Railsy będą szybsze, bardziej modularne i łatwiejsze w rozszerzaniu. Tylko czekać na wyniki refaktoryzacji :)

Postaram się w najbliższych tygodniach pisać o tym co dzieje się z Railsami3, jak idą prace i co jeszcze ciekawego będzie można zobaczyć.

Refaktoryzacja Railsów

2009-01-03T00:00:00-08:00

Niestety nie będzie to wpis o tym jak refaktoryzować swoją aplikację, ale raczej post o refaktoryzacji samego frameworka w ramach przygotowań do Rails 3.

Railsy pożarły mózg Merba i posiądą jego tajemne moce (zachęcam do wysłuchania tego podcastu, chłopaki od railsenvy genialnie mówią o tym co się dzieje w świecie railsów) – o tym już każdy na pewno wie. Czy to dobrze? Oczywiście, że tak :)

Jeżeli ktoś dalej ma problemy z tą decyzją (podejrzewam, że może tak być w wypadku fanów merba), polecam prezentacją Living with legacy software wygłoszoną przez Davida Heinemeiera Hanssona – nie jest w żaden sposób bezpośrednio związana z połączeniem, ale zmienia podejście do aplikacji i ich kodu.

Ale nie o to, nie o to, nie o to

Yehuda Katz ostro wziął się do pracy jeszcze podczas świąt i co jakiś czas wrzuca na bloga informacje o tym jak refaktoryzuje i jakie ma plany wobec Railsów. Informacje traktujące o projektowaniu, refaktoryzacji i architekturze ciężko jest znaleźć w sieci, więc gorąco polecam śledzenie tego co pisze Yehuda – do tej pory można przeczytać między innymi o enkapsulacji ActionView i ActionController czy o optymalizacji respond_to. Dodajcie sobie tego bloga do czytnika, naprawdę warto.

Co najlepsze, wiele z tych zmian dotyka tylko wewnętrznej implementacji railsów, więc można liczyć, że będą one dostępne dla ruby on rails 2.3.0.

To self or not to self?

2008-11-15T00:00:00-08:00

Czasami przeglądając kod różnych aplikacji można zauważyć kawałki wyglądające mniej więcej tak:

  attr_accessor :price

  def total_price
    p = items.inject(0) {|sum, item| sum + item.price }
    # więcej kodu
    p
  end

W prawdziwej aplikacji można to zobaczyć na przykład w Spree (użycie tot zamiast total)

p oznacza tutaj zapewne price, ale autor kodu intuicyjnie stwierdził, że pisząc “price =”, zamiast stworzenia nowej zmiennej przypisze wartość na atrybut price.

Rzeczywiście jest to intuicyjne i całkiem bezpieczne, ale zupełnie niepotrzebne. Spokojnie i bez żadnego problemu można użyć price. Dlaczego?

W rubim można opuścić słowo self jeżeli chodzi o odczytanie wartości metody. Jeżeli więc bez zadeklarowania zmiennej price ktoś napisałby puts(price), to ruby zinterpretowałby to jako chęć wyświetlenia self.price. Inaczej jest z zapisywaniem. Jeżeli wywołana jest metoda price=, to ruby stworzy nową zmienną.

Na przykład taki kod:

  class Product
    attr_accessor :price

    def initialize(price)
      self.price = price
    end

    def do_something_with_price
      price = 10
      puts price
      puts self.price
    end
  end

  p = Product.new(20)
  p.do_something_with_price

Wypisze:

10
20

Na koniec napiszę tylko, że mam mieszane uczucia co do korzystania z tych właściwości języka. Z jednej strony nie lubię jak w kodzie pałętają się skrótowe nazwy zmiennych, ale z drugiej strony taki zapis pokazuje, że chodzi nam o coś innego niż self.costam.

Ja z reguły staram się nie skracać nazw w takich wypadkach. Jakie jest wasze zdanie?

Named scope

2008-10-03T00:00:00-07:00

W railsach od jakiegoś czasu można używać named_scope. Jest to bardzo fajny mechanizm umożliwiający łatwiejsze skonstruowanie zapytania używając wcześniej zdefiniowanych metod. Wcześniej był dostępny jako plugin has_finder.

Wygląda to mniej więcej tak:

  named_scope :active, :conditions => { :active => true }
  named_scope :paid, :conditions => { :paid => true }
  named_scope :recent, lambda { { :conditions => ['created_at >= ?', 1.week.ago] } }

Po zdefiniowaniu takich sope’ów (macie pomysł jak to spolszczyć?) można ich używać w ten sposób (zakładam, że scope’y zostały zadeklarowane w modelu Product):

  Product.active.paid.recent

Jak można łatwo zauważyć, scope’y można łączyć w łańcuchy. Dzięki takiej konstrukcji otrzymujemy prosty i treściwy kod, który łatwo zrozumieć. Teraz coś lekko trudniejszego:

  named_scope :in_category, lambda { |category| { :conditions => { :category_id => category } } }
  
  # i użycie
  Product.active.recent.in_category(category)

O co chodzi? Jako 2 argument można przekazać lambdę, która zostanie wywołana przy użyciu scope’a i powinna zwrócić Hash.

Ale to nie są jedyne zastosowania scope’ów. Można do nich przekazać też inne parametry, które może przyjąć metoda find.

Na przykład order, offset i limit:

  named_scope :order, lambda { |*args| { :order => args.first || "created_at DESC" } } 
  named_scope :offset lambda { |offset| { :offset => offset } } 
  named_scope :limit, lambda { |*args| { :limit => args.first || 10 } } 
  
  # i użycie:
  Product.active.order("id DESC").offset(10).limit

W pierwszym i trzecim scope’ie zastosowałem trick, który pozwala na użycie zdefiniowanej wartości domyślnej w razie gdy żadna nie zostanie podana. `*args` pakuje argumenty do tablicy. Jeżeli args.first zwróci nil, to znaczy, że tablica jest pusta, czyli nie zostały podane żadne argumenty i trzeba zaaplikować wartość domyślną.

Coś jeszcze? Fajnie by było, żeby można było sortować nie tylko po wartościach z jednej tablicy… a do tego wypadałoby użyć joins/include. Nic prostszego.

  named_scope :joins, lambda { |joins| { :joins => joins } } 
  
  # a teraz można tak:
  Product.active.joins(:user).order('users.email')

How cool is that?

No i na koniec coś co ostatecznie przekonało mnie, że named_scope jest genialnym wynalazkiem. Jeżeli ktoś robił kiedyś formularze, w których można wybrać kilka opcji i na ich podstawie trzeba zbudować zapytanie, zapewne wie, że jest to nieco upierdliwe. Używając `named_scopes` można to zrobić bardzo łatwo.

Ryan Bates napisał plugin scope_builder, dzięki któremu można to zrobić jeszcze łatwiej. Przypuśćmy, że mamy formę, w której można zaznaczyć kilka pól i po ich wysłaniu należy na ich podstawie pobrać odpowiednie rekordy z bazy.

  # przygotowujemy listę parametrów, które użytkownik może ustawić
  parameters = [:active, :paid, :recent, :title]
  # Tworzymy scope
  @products = Product.scope_builder
  # teraz można sprawdzić, które pola zostały zazanczone
  parameters.each do |param|
    @products.send(param) if params[param]
  end
  # na koniec można na przykład dodać paginację
  @products = @products.paginate(:per_page => 10, :page => params[:id])

Dla mnie genialne. :) Można dzięki temu łatwiej tworzyć zaawansowane wyszukiwanie, sortowanie i inne tego typu rzeczy.

Oczywiście najlepiej jest zamknąć taki kawałek kodu jako metodę modelu, zgodnie ze skinny controller, fat model, ale to pozostawię jako ćwiczenie ;-)

Po dłuższej przerwie

2008-09-30T00:00:00-07:00

Przez jakiś czas nie pisałem nic na blogu. Długo zbierałem się do napisania czegokolwiek, od dawien dawna miałem przetłumaczyć wpisy na moim angielskojęzycznym blogusiu. Tak bardzo mi się nie chciało, że jak tylko siadałem do kompa z zamiarem przetłumaczenia czy napisania czegoś podobnego coś mnie odrzucało.

Dlatego, żeby więcej się nie męczyć podsumuję ten temat i podam linki – większość ludzi, którzy tutaj trafią i tak na pewno zna angielski.

Napisałem apache upload progress module do apacha. Moduł, dzięki któremu można pobrać dane o wysyłanych plikach. Format odpowiedzi oparłem o moduły tego typu dla nginxa i lighttpd dlatego jeżeli wcześniej ktoś używał któregoś z nich, przesiadka będzie całkowicie bezbolesna. Sam używałem wcześniej nginx upload progress (głównie dlatego napisałem moduł do apacha) i po przerzuceniu aplikacji na apacha z nowym modułem nie trzea było zmieniać ani jednej linijki. Na angielskim blogu zamieściłem opis instalacji i konfiguracji modułu.

Żeby można było w miarę łatwo używać modułu napisałem także pluginy do "prototype’a"http://github.com/drogus/prototype-upload-progress/tree/master i jquery, które obsługują pasek postępu. Przykłady są w repozytoriach, umieściłem je także na serwerze dla obczajenia w akcji. Popełniłem także tekst o tym jak hackowałem plugin, żeby działał w safari – safari w tym momencie nie było wcale lepsze od IE… nawet powiedziałbym, że gorsze. Swoją drogą plugin nie działa w najnowszej operze (działał w 9.5 zdaje się), więc jeżeli ktoś ma chwile czasu i mógłby sprawdzić dlaczego i co można zrobić, żeby działał, to może wnieść swój wkład w rozwój (dodam, że nie jest to ta sama kwestia co dla safari, bo to już sprawdziłem) – nie sądzę żebym miał teraz czas sam na tym siedzieć.

Dodatkowo napisałem jeszcze tekst o tym jak można fajnie uatrakcyjnić aplikację używając jQuery. Część pierwsza. Część druga będzie jak będę miał więcej czasu, czyli pewnie niezbyt szybko.

Pozdrowienia ze słonecznego Wrocławia, gdzie mam zamiar mieszkać przez najbliższy rok (miła odmiana od Pruszkowa :).

2 przydatne rzeczy w gicie

2008-06-03T00:00:00-07:00

Usuwanie gałęzi ze zdalnego repozytorium:

git push {repository} :heads/{your_branch_here}

Usuwanie pliku z indexu bez usuwania go z systemu plików (przydatne gdy dodamy do .gitignore plik, który już istnieje):

git-update-index --force-remove sciezka/do/pliku

Taki szybki pościk ;-)

Git

2008-04-08T00:00:00-07:00

Jeżeli ktoś jeszcze nie zauważył społeczność frameworków Ruby on Rails i Merb przesiada się powoli na rozproszony system kontroli wersji Git. Na gita przechodzą Railsy, przeszedł już Merb, Rspec, sporo koderów wypuszczających popularne pluginy. Jednym słowem coś w tym musi być.

I rzeczywiście coś w tym jest.

O co chodzi? Jarosław Zabiełło na swoim blogu przedstawił kilka rozproszonych systemów kontroli wersji.

Jakie są zalety gita?

każdy posiadający kopię aplikacji posiada też całe repozytorium. Coś się rozwaliło? Trzeba zmienić serwer? Serwis,a na którym hostowałeś SVN’a padł? Smuteczek. Ale nie z gitem – repozytorium, które masz na dysku wystarczy.
Git jest dużo szybszy od SVNa
“Mobilność” – bardzo ważna dla mnie kwestia. Często wyjeżdżam i zdarza mi się pracować bez dostępu do netu. W przypadku SVNa musiałem wrzucić jeden mega commit z pierdylionem zmian. W przypadku gita commity lecą do repozytorium na dysku i później można je ewentualnie pchnąć (push) do publicznego repo.
Bardzo łatwa obsługa gałęzi. Pracując z gitem najlepiej wyrobić sobie nawyk tworzenia gałęzi przy każdej zmianie, lub grupie połączonych ze sobą zmian. Dzięki temu można pracować równolegle nad wieloma rzeczami nie zaśmiecając aplikacji. Później tylko łączymy gałęzie, które rzeczywiście są potrzebne, jeżeli coś nie wyjdzie można po prostu daną gałąź wyrzucić i po krzyku
dużo łatwiejsze wrzucanie zmian do projektów open source’owych, szczególnie z pomocą githuba (ale o tym za chwilę).

Ale kod leżący cały czas na dysku będzie mało przydatny. Dlatego można założyć sobie publiczne repozytorium. Stwierdziłem jakiś czas temu, że w trosce o swój czas, którego zawsze za mało, będę musiał ograniczyć wszelkie prace, których mogę stosunkowo łatwo uniknąć. Dlatego nie bawiłem się nawet w tworzenie swojego własnego publicznego repozytorium. Wygodniej skorzystać pracy innych ludzi ;-)

Obecnie najbardziej popularne (jedyne?) serwisy oferujące hosting repozytoriów gita to: GitHub i Gitorius. Gitorius jest w pełni darmowy, ale nie można na nim trzymać prywatnych repozytoriów. Na githubie za darmo można trzymać publiczne repozytoria (ogranicza nas 100mb – jeżeli chodzi o gita to bardzo dużo), za prywatne trzeba będzie zapłacić. Na razie można jeszcze korzystać za darmo, bo serwis jest w fazie beta.

Zarejestrowałem się na Githubie kilka dni temu i przeniosłem tam 2 ze swoich projektów. Github to bardzo fajny pomysł na stworzenie społeczności koderów (napisany oczywiście w railsach). Co daje taki serwis?

dostęp do rss’ów poszczególnych użytkowników, projektów, feed z wiadomościami z obserwowanych projektów
można jednym kliknięciem zrobić kopię aplikacji (fork) – jakie są tego korzyści opisał na blogu jeden z developerów merba Michael Ivey :Contributing to merb
można wysłać znajomym “pull request” – czyli prośbę o uaktualnienie, na przykład po ważnej aktualizacji

Dodatkowo dostajemy wszystkie zalety gita.

No to co? Przesiadka na jasną stronę mocy, z tego fuj fuj obleśnego i niefajnego SVNa, który tak chwaliłem kiedy się z nim zapoznałem ;-)

HotRuby

2008-04-05T00:00:00-07:00

Jakiś czas temu pojawiły się wzmianki o hotruby (tylko wtedy nie miałem czasu o tym napisać). Krótko mówiąc jest to “implementacja rubiego w javascripcie”. Możemy używać rubiego w przeglądarce i we flashu.

Kod rubiego jest wysyłany do skompilowania przez skrypt cgi, skrypt cgi kompiluje go do bytecodu, po czym javascript wykonuje ów bytecode.

Na stronie HotRuby jest wzmianka o tym, że składnia języka jest w większości zaimplementowana (na pewno nie ma wyjątków), ale jak na razie większość funkcji i bibliotek nie. Na razie nie wiem do czego mogłoby mi się takie połączenie przydać, ale patrząc na dema łatwo można zauważyć, że całkiem fajne rzeczy da się stworzyć z pomocą hotrubiego. Oby tak dalej.

Rails 2.0 i js.erb

2008-01-15T00:00:00-08:00

Niedawno pisałem o nieinwazyjnym kodzie javascript w railsach. Wspomniałem tam o pluginie MinusMor, który dodaje pliki ejs. Czyli kod javascript parsowany erbem. Zainstalowałem plugin w mojej aplikacji przeniesionej na rails 2.0. Kod pluginu nie działa… zacząłem przeglądać kod railsów, żeby poprawić minusmor (w internecie nie mogłem znaleźć poprawki). Po chwili przemyślenia sprawdziłem co dzieje się gdy wyrzucę plik rjs. Komunikat o błędzie:

Missing template pages/index.js.erb in view path

Git! W railsach 2.0 możemy przecież wskazać jakiego parsera mają użyć.

Tworzymy plik index.js.erb. I jeszcze mała zmiana, ustawiamy brak layoutu, żeby renderował się sam template:

respond_to do |format|
  render.html
  render.js { render :layout => false }
end

I to wszystko! Po prostu działa.

Nawet lepiej. Można zdefiniować layout, na przykład:

render.js { render :layout => 'jquery' }

a w nim można na przykład napisać:

(function ($) {
  <%= yield %>
})(jQuery);

I można używać w template’ach js.erb $ pomimo tego, że wcześniej użyło się jQuery.noConflict.

Przeszukałem później jeszcze net w poszukiwaniu informacji na ten temat i znalazłem artykuł na mad.ly o dodaniu helperów z MinusMor

Web3.0 - boję się!

2008-01-13T00:00:00-08:00

Pan Urbanowicz, znawca internetu, napisał tekst o (uwaga uwaga, fanfary) Web3.0! A w nim przestraszył mnie nieźle:

Ale Web 3.0 niesie ze sobą również wiele zagrożeń: naruszanie swobód obywatelskich, kradzież danych, stopniową dehumanizację czy czipy biometryczne, będące w stanie śledzić wszystkie nasze ruchy. Jak w „Raporcie mniejszości", każdy nasz krok będzie rejestrowany przez kamery, które będą komunikować z komputerami, a te porozumiewać się z serwisami identyfikującymi twarze. Kto wie, jak daleko może posunąć się inwigilacja ze strony agencji rządowych?

Oba światy: wirtualny i rzeczywisty będę się wzajemnie przenikały, automatycznie wzrośnie ilość spamu, wirusów i hakerów. Będzie więcej dezinformacji, więcej manipulacji i więcej cenzury. Web 3.0 nie będzie nas chronił bardziej niż Web 2.0, wprost przeciwnie, będziemy jeszcze bardziej narażeni na niebezpieczeństwa. Tworzymy świat, który trudno nam zrozumieć, a co dopiero mówić o jego kontroli.

Szkoda, że nie ma nic o głodzie, wojnach, najeźdźcach z kosmosu i pani Czesi spod piątki, która awanturuje się o każdą rzecz.

Boże, miej nas w swojej opiece! Albowiem Armagedon 3.0 nadchodzi!

Przyjazne adresy w Ruby on Rails

2008-01-12T00:00:00-08:00

W dzisiejszych czasach, kiedy SEO dla niektórych jest ważniejsze od treści przyjazne adresy można zobaczyć na większości stron. Dlaczego nie wrzucić ich do naszej aplikacji? Nawet jeżeli komuś nie zależy na SEO, przyjazne adresy są… przyjazne! Użytkownik dostający linka http://foo.com/article/kolejny-artykul-o-naszej-klasie będzie miał szansę zastanowić się sekundę i nie kliknąć (nie to żebym miał coś do naszej klasy, ale boję się ostatnio lodówkę otworzyć, jeszcze szynka zacznie nawijać kogo dodała do znajomych). Same korzyści!

Dodanie przyjaznych adresów jest w aplikacji railsowej bardzo proste jeżeli trzymamy się kilku zasad. Jak to działa? ActiveRecord::Base, po którym dziedziczą udostępnia metodę to_param, która jest wykorzystywana przy generowaniu adresów.

W praktyce wygląda to tak, że jeżeli napiszemy:
<pre> link_to @article.name, articles_path(@article) #albo link_to @article.name, :controller => "articles", :action => "show", :id => @article </pre>

wywołana zostanie metoda to_param i @article zostanie zamieniony na jego id. Można to wykorzysta do naszych niecnych celów.

Można nadpisać to_param
<pre> def to_param "#{id}-#{name.gsub(/[^a-z0-9]+/i, '-')}" end </pre>

Od teraz zamiast id będzie generował się string zawierający name, na przykład: “11-tytuł-artykułu”. Hamerykanie mają mniejszy problem, bo nie mają znaków diakrytycznych i mogą to tak zostawić. gsub zamieni wszystkie znaki nie wchodzące w skład alfabetu na myślnik. U nas jest gorzej, bo nie chcemy mieć adresu: “11-tytu-artyku-u”. I weź teraz zgaduj gdzie dorzucić ogonki. Z pomocą przychodzi Obie Fernandez, który napisał najfajniejszą jaką do tej pory widziałem metodą zamieniającą znaki diakrytyczne na odpowiadające im litery alfabetu
Wrzuciłem na serwer wersję z polskimi znakami diakrytycznymi. Taki plik wystarczy wrzucić do folderu initializers dla Railsów 2.0.x, albo do katalogu lib dla 1.2.x (w tym wypadku trzeba też w environment.rb dodać linijkę require ‘ascii’). Zrobiłem jeszcze jedną modyfikację – to_url_format powinien moim zdaniem w miejsce spacji i innych znaków wrzucać myślniki. Lepiej wygląda “tytul-artykulu” niż “tytulartykulu”.

Dzięki temu String udostępnia 2 nowe metody: `to_url_format` i `to_ascii`:
<pre> "zażółć gęślą jaźń".to_ascii #=> "zazolc gesla jazn"

“zażółć gęślą jaźń”.to_url_format #=> “zazolc-gesla-jazn”

Teraz wystarczy zmodyfikować lekko to_param:
<pre> def to_param "#{id}-#{name.to_url_format}" end </pre>

Dzięki temu urle będą miały upragnioną formę: “12-tytul-artykulu”.

Tylko po co to id na początku? Dzięki temu obędzie się bez żadnych zmian w kontrolerach. Taki string zostanie przed wrzuceniem do bazy automatycznie skonwertowany na liczbę całkowitą. Czyli kolejna rzecz, która “po prostu działa” automagicznie. Jeżeli id będzie potrzebne w jakimś innym miejscu, w którym nie nastąpi konwersja można to zrobić ręcznie: params[:id].to_i, bo:
<pre> "11-jakis-napis".to_i #=> 11 </pre>

Jaki jest minus takiej metody? Adresy mają w sobie id i tylko na podstawie tego id jest pobierany artykuł, więc czy wpiszemy /articles/11-tytul-artykulu, czy /articles/11-tralalala pobierze się ten sam artykuł.

Żeby temu zapobiec najlepiej zrobić dodatkową kolumnę, na przykład “permalink” i wpisywać do niej przekształcony adres. Np. article.permalink = article.name.to_url_format . I zamiast po id szukać po kolumnie permalink: Article.find_by_permalink(params[:id]). Oczywiście z metody to_param też trzeba usunąć id :)

Nie każdemu to drugie podejście będzie potrzebne. Dla mnie wersja z id jest o tyle lepsza, że jak nawet ktoś nie skopiuje całego adresu, albo pomyli się przy wpisywaniu (tak, czasami zdarza się, że ktoś dyktuje jakiś adres), to jest duża szansa, że dotrze na dobrą stronę. Poza tym istnieje wtedy możliwość wklejenia adresu bez dalszej części, która może być dość długa – może nie trzeba będzie korzystać z serwisów typu tinyurl.

Wrzuciłem nową wersję skryptu działającą z nowszymi wersjami Ruby on Rails

Otwarte klasy w Rubim i ich praktyczne wykorzystanie

2008-01-08T00:00:00-08:00

Ruby posiada bardzo fajną właściwość nazwaną otwartymi klasami. Znaczy to tyle, że jeżeli nikt nie zamroził danej klasy/metody, można w dowolnym miejscu w kodzie nadpisać ją klasę, metodą, dodać nowe metody. Można tak nadpisać nawet klasy wbudowane w język!

Na przykład taki kod (och jak ja lubię ten przykład):

class Fixnum
  alias old_plus +

  def +(other)
    (self.old_plus other) % 7
  end
end

4+4 #=> 1

4+4=1 ? nie tego się spodziewaliśmy. A właściwie nie tego się spodziewali ludzie, którzy nie rozumieją jeszcze powyższego przykładu (celowo dodałem słowo jeszcze, będę na tyle cywilizowanym i miłym człowiekiem, że spróbuję wytłumaczyć o co chodzi).

Liczby całkowite są klasy Fixnum. Powyższy kod modyfikuje tą klasę. Najpierw tworzony jest alias dla metody +, żeby można było jej później używać, a następnie owa metoda zostaje nadpisana w taki sposób, żeby zwracała wynik dodawania modulo7

Do napisania tego artykułu natchnął mnie Daniel Owsiański pisząc o zjawisku roboczo nazwanym version lock-in. Daniel ma oczywiście dużo racji i moja paranoja, o której pisałem u niego w komentarzach jest objawem przewrażliwienia mojej mózgoczaszki w pewnych kwestiach. Są jednak wypadki, w których naprawdę warto zachować zgodność z nowymi wersjami. Pomaga tutaj powyższa właściwość języka Ruby. Pisał o tym kiedyś autor bloga Err the Blog w kontekście rozszerzania możliwości pluginów.

Często w rozmowach o Ruby on Rails na różnych listach dyskusyjnych można usłyszeć, że gdy chcemy coś zmienić w danej metodzie, najlepiej przekopiować kod metody, nadpisać ją, zmienić to co trzeba i voilla. Ale nie tędy droga panie i panowie :)

Wyglądałoby to mniej więcej tak. Chcemy na przykład nadpisać metodę find. Wchodzimy na Rails API, znajdujemy ActiveRecord::Base#find, wklejamy kod w modelu i zmieniamy:

#w modelu:
def self.find(*args)
  #jakiś zmodyfikowany kod finda
end

Jakie minusy ma takie podejście? Gdy mamy zainstalowaną dużą liczbę pluginów nigdy nie wiadomo czy któryś z nich nie nadpisuje już metody find i wtedy nadpisując ją stracimy funkcjonalność dodaną przez plugin. Smuteczek. Poza tym gdy zmieni się kod metody find w samym frameworku również u nas będziemy musieli go zmienić.

Jak to zrobić Ruby Way™? Przypuśćmy, że chcemy się popastwić nad wspomnianą metodą find:

#w modelu:

# metoda find jest metodą klasy
class << self
  def find(*args)
    args[1] ||= {}
    args[1][:conditions] ||= {} 
    args[1][:conditions] = [args[1][:conditions]] if args[1][:conditions].is_a?(String)
    case args[1][:conditions]
      when Hash: 
        args[1][:conditions].merge!(:deleted => false)
      when Array:
        if args[1][:conditions][0].strip.blank?
          args[1][:conditions][0] = "deleted = ?"
        else
          args[1][:conditions][0] = ["(#{args[1][:conditions][0]})", "deleted = ?"].join(' AND ')
        end
        args[1][:conditions] << false       
    end
    super(*args)
  end
end

Powyższy kod dodaje do conditions warunek “deleted = false”, po czym wywołuje metodę find z tak zmodyfikowanymi argumentami. Czasami trzeba jednak namieszać coś w kodzie metody. Można wtedy dodać dodatkowy argument. Następnie dajemy ifa – jeżeli argument zwraca true wykonujemy zmodyfikowany kod, a jeżeli nie, wykonujemy kod oryginalnej metody.

Dzięki takiemu podejściu możemy w miarę łatwo upgradować pluginy i Railsy bez większego stresu :)

Thin. Nowy lepszy mongrel. Sphinx. Nowy lepszy ferret.

2008-01-06T00:00:00-08:00

Jak donosi Ruby Inside, wypuszczony został ostatnio serwer szybszy od mongrela.

Chodzi o Thin, czyli połączenie EventMachine, Racka (interfejs do komunikacji z serwerem) i Mongrela (a dokładniej jego bibliotek do parsowania). Instalacja i użycie jest równie łatwe co użycie samego mongrela. `gem install thin`, a później w katalogu aplikacji `thin start`. Jedna z moich aplikacji wyciągała na mongrelu 110req/s, a na thinie około 150req/s (ab -c 10 -n 100). Różnica całkiem spora. Warto się przesiąść

Sprawdziłem też ostatnio sphinxa. O sphinxie pisał już Jarosław Zabiełło i bardzo mnie powyższym artykułem zainteresował. Do tej pory używałem ferreta, ale odpalanie nie do końca stabilnych i niezbyt szybkich serwerów dla każdej aplikacji było trochę uciążliwe. Ezra Zygmuntowicz, twórca frameworka Merb wypowiadał się, że miał dość duże kłopoty ze stabilnością ferreta, które skończyły się po przejściu na sphinxa.

Instalacja opisana jest w dokumentacji, więc nie będę powtarzał :) Mogę dodać jedynie, że czasami używając bazy postgresql trzeba ręcznie dodać language poleceniem `createlang plpgsql nazwa_bazy` (chodzi o nowy język proceduralny dla postgresa). Serwer odpalony przez sphinxa jest bardzo wydajny i zajmuje kilkadziesiąt razy mniejsze ilości pamięci operacyjnej. Jedynym minusem jest to, że nie ma niektórych opcji, które posiada ferret – jeżeli ktoś ich potrzebuje proponuję sprawdzenie Solr.

Zapomniałem wspomnieć, że ultrasphinx działa z bazami postgresql >= 8.2

God.rb

2008-01-05T00:00:00-08:00

Wpadłem jakiś czas temu na bardzo fajną aplikację wspomagającą deployment Ruby on Rails. god.rb monitoruje procesy i w razie potrzeby (out of memory, zbyt dużo pożartego cpu, pad serwera) restartuje je. Config, jak i sam god oczywiście, jest napisany w Ruby’im, więc można sobie nieco ułatwić pracę (wspominałem kiedyś, że nigdy nie miałem dość samozaparcia, żeby się nauczyć pisać skrypty powłoki pod linuxem?).

Aby go zainstalować należy jako root (pod ubuntu sudo) wykonać polecenie:

gem install god

Na stronie goda są podane różne configi, ale nie zakładają one scenariusza: “sporo aplikacji, taki sam config, jak to zrobić automatycznie?”. Pomyślałem sobie, że napiszę prosty config, który będzie pobierał listę aplikacji Rails z pliku i dodawał mongrele do monitorowania. Gdy na serwerze siedzi więcej aplikacji głupio byłoby kopiować config dla każdej z nich i ręcznie ustawiać numery portów i katalogi.

Pełny config z komentarzami wyjaśniającymi o co kaman (wersja tekstowa):

# run with:  god -c /path/to/config.god<span class="c1"># run with:  god -c /path/to/config.god</span>
require 'yaml'
# otwieramy plik ze spisem aplikacji i robimy z nich tablicę

rails_apps = File.open("/etc/god/applications", "r").readlines.collect { |app| app.strip }
for rails_app in rails_apps

  # załadujmy ustawienia danej aplikacji

  # korzystać będziemy z konfiguracji dla clusterów

  config = YAML::load(File.open(File.join(rails_app, "config/mongrel_cluster.yml")))

  config["servers"] ||= 1 # domyślnie startujemy jeden serwer
# teraz stawiamy mongrela dla każdego portu
((config["port"].to_i)..(config["port"].to_i+config["servers"].to_i-1)).each do |port|
God.watch do |w|
pid_file = File.join(rails_app, config["pid_file"].gsub(/\.pid$/, ".#{port}.pid"))
w.name = "#{rails_app[/[^\/]*$/]}-mongrel-#{port}"

# dodajemy mongrele danej aplikacji do grupy o nazwie takiej samej jak nazwa katalogu
w.group = "#{rails_app[/[^\/]*$/]}"
w.interval = 30.seconds # default      
w.start = "mongrel_rails start -c #{rails_app} -p #{port} \
        -P #{pid_file}  -e #{config['environment']}  -d"

      w.stop = "mongrel_rails stop -P #{pid_file}"

      w.restart = "mongrel_rails restart -P #{pid_file}"

      w.start_grace = 10.seconds

      w.restart_grace = 10.seconds

      w.pid_file = File.join(pid_file)
w.behavior(:clean_pid_file)

w.start_if do |start|
start.condition(:process_running) do |c|
c.interval = 5.seconds
c.running = false
end
end

w.restart_if do |restart|
restart.condition(:memory_usage) do |c|
c.above = 150.megabytes
c.times = [3, 5] # 3 out of 5 intervals
end

restart.condition(:cpu_usage) do |c|
c.above = 50.percent
c.times = 5
end
end

# lifecycle
w.lifecycle do |on|
on.condition(:flapping) do |c|
c.to_state = [:start, :restart]
c.times = 5
c.within = 5.minute
c.transition = :unmonitored
c.retry_in = 10.minutes
c.retry_times = 5
c.retry_within = 2.hours
end
end

end
end
end
puts "kuniec"




Aplikacje w pliku, który jest odczytywany na początku to ścieżki wpisane w kolejnych liniach. gdy wystartujemy goda poleceniem `god -c /sciezka/do/configu` uruchomią się mongrele dla wszystkich aplikacji. Ważne: powyższy config korzysta z konfiguracji stworzonych dla clusterów. Aby ją stworzyć należy wykonać w katalogu aplikacji:
mongrel_rails cluster::configure -e production -p 8000 -N 2


Powyższa komenda wygeneruje plik `mongrel_cluster.yml` w katalogu config aplikacji Ruby on Rails. Zostanie ustawione środowisko production, port 8000 i 2 serwery (na portach 8000 i 8001).
Żeby szczęście było pełne i niczym niezmącone można jeszcze pokusić się o napisanie skryptu startowego init.d. Oczywiście w ruby’im. A jakie to proste pokazywał kiedyś Jarek Zebiełło.
W razie wątpliwości pytajcie o szczegóły w komentarzach.



Nieinwazyjny javascript razem z Ruby on Rails
2007-12-25T00:00:00-08:00
Jakiś czas temu Riddle napisał o tym dlaczego nie można zakładać, że ktoś ma włączony javascript. Temat był już wcześniej wiele razy poruszany, mi bardzo podobał się artykuł Chrisa Heilmanna The seven rules of Unobtrusive JavaScript. Zachęcam do zapoznania się z tymi dwoma tekstami – pomogą zrozumieć dlaczego “tracić” czas na rozwiązywanie problemów, o których napiszę poniżej. Streszczając krótko artykuły mogę napisać, że jeżeli to możliwe, należy pisać aplikację tak, żeby działała bez włączonego javascriptu. Skrypty mogą nie działać z kilku powodów:

	użytkownik ma wyłączony javascript w przeglądarce
	wystąpi błąd w kodzie (nie możemy sprawdzić kodu na wszystkich urządzeniach)
	strona nie załaduje się do końca
	boty wyszukiwarek nie używają javascriptu, więc w skrajnym wypadku możemy uniemożliwić zindeksowanie naszej strony

Jak to wygląda w Railsach?
Railsy są wyposażone w zestaw helperów generujących różnego rodzaju kawałki kodu javascript. Pomysł jest z pozoru bardzo fajny. Początkujący mogą szybko zacząć używać javascriptu razem z dobrodziejstwami, które daje nam Ajax bez znajomości samego języka. Jest jednak sporo minusów używania helperów:

	generują one dodatkowy niepotrzebny kod javascript. jeżeli na stronie mamy kilkadziesiąt linków, a każdy z nich ma wklejony kod `onclick=“new Ajax.Request(‘/controller/action?n=33’, {asynchronous:true, evalScripts:true, onComplete:function(request){undoRequestCompleted(request)}}); return false;”` strona będzie ważyć dużo więcej.
	javascript w nich użyty jest “inwazyjny”. Jeżeli javascript nie będzie działał, to element wygenerowany w taki sposób również nie zadziała^1^
	ciężko jest się przy nich trzymać zasady DRY. Mając 5 linków wygenerowanych metodą link_to_remote z takimi samymi opcjami, za każdym razem gdy coś musimy zmienić, zmieniamy to w 5 miejscach. Powinno się oczywiście napisać helpera, który wygeneruje link z danymi opcjami. Tylko chyba nie tędy droga – w dalszej części artykułu postaram się pokazać dlaczego nieinwazyjny javascript jest lepszy w tego typu zadaniach.
	z mojego doświadczenia wynika, że bardzo często, gdy ilość kodu się powiększa i javascript generowany przez railsy miesza się z tym z plików js można łatwo się pogubić. Tyczy się to także różnego rodzaju api – na przykład google maps. Najłatwiej działać, gdy javascript jest odseparowany od kodu railsów
	jesteśmy związani z jedną biblioteką (w tym wypadku prototype+script.aculo.us) – jeżeli chcemy zamienić ją na coś innego (ja ostatnio przesiadłem się na jQuery, zastanawiałem się też nad YUI) helpery przestaną działać – można je oczywiście przepisać, ale komu by się chciało. DHH nie zamierza nic w tej kwestii zmieniać, więc na zmianę tego w Railsach nie ma co czekać.

Jakie są minusy? Trzeba lepiej poznać javascript (właściwie dla mnie to nie jest minus, ale dla niektórych być może tak). Nie jest to jednak przeszkoda nie do pokonania dla początkujących. Javascript, który jest potrzebny do zadań możliwych do wykonania z użyciem samych helperów nie jest z reguły przesadnie trudny do nauczenia. Ratunkiem dla osób, które nadal chcą korzystać z helperów jest plugin UJS. Jeżeli bardzo nie chcesz pisać wszystkiego w czystym javascripcie, to jest to bardzo fajne połączenie prostoty helperów i zalet nieinwazyjnego javascriptu. Jest ona jednak pisana dla Prototype’a, więc tak jak w ostatnim punkcie z powyższej listy można o niej zapomnieć, jeżeli używana jest jakakolwiek inna biblioteka.
W komentarzach apohllo zauważył, że plugin UJS nie jest już rozwijany. Używacie na własną odpowiedzialność. :)
Przejdę do przykładów, bo przecież nie samą teorią człowiek żyje.
Przerzuciłem się ostatnio na jQuery i chyba przy niej zostanę. Rozumiem jednak, że większość użytkowników railsów jest związana z Prototype’em, więc kod będę podawał w dwóch wersjach, dla Prototype’a i jQuery.
Na początek wprowadzenie. Co zrobić, żeby wyrzucić z htmla (i railsów) wstawki Javascript? Wszystko wstawiamy do aplikacji używając zdarzeń. Przypuśćmy, że mamy linka o id=“someLink”. Zamiast dopisania onclick:
  <a href="#" onclick="alert('Klik!'); return false;">Link</a>


należy użyć:
Prototype:
  Event.observe($('someLink'), 'click', function(event) {
    alert('Klik!');
    Event.stop(event);
  }


jQuery:
  $('#someLink').click(function (){
    alert('Klik!');
    return false;
  });


Oba przykłady dodają zdarzenie uaktywniane kliknięciem w linka. Ostatnia linijka w obu funkcjach, które są wykonywane po kliknięciu (nazywane są z reguły handlerami) jest wstawiona po to, żeby kliknięcie linka nie przeładowało strony.
Kod taki w aplikacji Rails można wrzucić do pliku application.js, lub jakiegoś specyficznego pliku js ładowanego na danej stronie. Należy też go załadować dopiero po wczytaniu się całego dokumentu. Normalnie coś takiego uzyskiwało się wpisując w body: `onload=“jakasFunkcjaJavascript();”`, ale takie dodawanie jest passe, więc:
Prototype:
  Event.observe(window, 'load', function() {
    //kod który wykona się po załadowaniu strony
  }

  // lub zdefiniowana wcześniej funkcja, która wykona się po załadowaniu strony
  Event.observe(window, 'load', jakasFunkcjaJavascript());


jQuery:
  $(function() {
    //kod który wykona się po załadowaniu strony
  });
  
  // lub zdefiniowana wcześniej funkcja, która wykona się po załadowaniu strony
  $(jakasFunkcjaJavascript);
  //powyższe przykłady, to skrócone wersje document.ready:
  $(document).ready(function () {});


Dzięki tym konstrukcjom mamy pewność, że kod wykona się dopiero gdy załaduje się cały dokument, a nie w momencie, gdy dołączony jest plik js.
Teraz przykład prostego zapytania ajax (przykład z dokumentacji railsów):
  link_to_remote 'hello', :url => { :action => "action" }, 
    404 => "alert('Not found...? Wrong URL...?')",
    :failure => "alert('HTTP Error ' + request.status + '!')"
  # Wygeneruje: <a href="#" onclick="new Ajax.Request('/testing/action', {asynchronous:true, evalScripts:true,
  #            on404:function(request){alert('Not found...? Wrong URL...?')},
  #            onFailure:function(request){alert('HTTP Error ' + request.status + '!')}}); return false;">hello</a>



Jak widać powyżej wygenerowanego kodu jest całkiem sporo. Jeżeli będzie trzeba wstawić taki link w paru miejscach dobrze by było napisać swojego własnego helpera, który automatycznie będzie wklejał komunikaty o błędach.
Jak można to zrobić lepiej? Na początek wystarczy stworzyć zwykłego linka z jakąś klasą, lub id:
  link_to 'hello', { :action => 'action' }, :class => 'ajax'



Teraz trzeba użyć trochę javascriptu :
        $$('a.ajax').each(function (element) {
          Event.observe(element, 'click', function(event) {
            new Ajax.Request(this.readAttribute('href'), {asynchronous:true, evalScripts:true, 
              on404:function(request){alert('Not found...? Wrong URL...?')}, 
              onFailure:function(request){alert('HTTP Error ' + request.status + '!')}}); 
            Event.stop(event);
          });
        });



Na początku pobieramy wszystkie linki z klasą ajax i dla każdego z nich wywołujemy funkcję `Event.observe(element, ‘click’….`. Dalszy kod wykona się więc po kliknięciu w danego linka. W tym wypadku wykonujemy zapytanie ajaxowe (`new Ajax.Request`). Pierwszy argument to atrybut href linka (uwaga, kod ten nie zadziała w starszych wersjach prototype’a, które niepoprawnie obsługiwały this w tego typu funkcji). Reszta kodu to standardowe opcje, po więcej odsyłam do dokumentacji Prototype.
A w jQuery wyglądać to będzie tak:
    $('a.ajax').click(function (){
      $.ajax({
        url: this.href,
        dataType: "script",
        beforeSend: function(xhr) {xhr.setRequestHeader("Accept", "text/javascript");},
        error: function(){
          alert( "Error loading page");
        }
      });     
      return false;
    });


Kod zasadniczo robi to samo, co poprzedni przykład. Można przy okazji porównać prostotę jQuery i porównać ją z Prototype’em (ostatnio dużo się w tej bibliotece pozmieniało, a ja nie jestem na bieżąco, więc jeżeli ktoś zna lepszy sposób na napisanie czegoś takiego, to proszę o komentarz). Skomentuję tylko atrybuty dataType i beforeSend w funkcji ajax(). Ustawiając je w taki sposób przekazujemy serwerowi, że chcemy dostać odpowiedź jako skrypt i akceptujemy typ MIME “text/javascript”. Należy te 2 rzeczy dodać, ponieważ inaczej nie będzie renderować się plik RJS. Więcej na ten temat w artykule jQuery Ajax + Rails
Rozwiązanie proste i efektywne. Żeby link wykonał javascript wystarczy dodać do niego klasę ajax. Jeżeli strona i kody javascript nie wczytają się, link dalej będzie działał poprawnie. Przy założeniu, że poprawnie obsłużymy wszystko w kontrolerze. Służy do tego metoda `respond_to`
  respond_to do |format|
    format.js # jeżeli to zapytanie wykonane ajaxem uruchomi się plik RJS
    format.html # w przeciwnym wypadku wyrenderowany zostanie template rhtml
  end


Więcej o takim sposobie renderowania templatów pisał na przykład Jamis Buck.
Można też w podobny sposób zamienić zwykłą formę na taką wysyłaną ajaxem:
Prototype:
     $$('form.ajax').each(function (element) {
        Event.observe(element, 'submit', function(event) {
          new Ajax.Request(this.readAttribute('action'), {
            parameters: Form.serialize(this),
            asynchronous:true, 
            evalScripts:true
            }); 
          Event.stop(event);
        });
      });  


Powyższy kod jest bardzo podobny do poprzedniego przykładu. Różnica polega na tym, że zdarzeniem nie jest ‘click’ tylko ‘submit’ i jako parametry podajmy wynik funkcji `Form.serialize(this)` – zbiera ona wartości pól i zwraca string typu: “pole1=wartosc1&pole2=wartosc2”
jQuery:
  $("form.ajax").ajaxForm({
    dataType: 'script',
    beforeSend: function(xhr) {xhr.setRequestHeader("Accept", "text/javascript");},
    resetForm: true
  });



W jQuery najłatwiej skorzystać z pluginu jQuery Form – załatwia on za nas wszelkie formalności ;-)
W ten sposób zmiana jakiegoś linka lub formy na jego ajaxową formę to kwestia dodania jednej klasy. Można oczywiście napisac wiele takich funkcji dla różnych przypadków, dowiązanych do tagów z innymi klasami, lub z konkretnym id.
Na koniec krótkie podsumowanie.
Kod javascript dodajemy do aplikacji tak, żeby nie zablokować dostępu w wypadku braku jego wykonania. Zapomnieć można o wszelakich “onclick” i innych tego typu sprawach. Wszystko powinno być dołączone jako zdarzenia. Dzięki temu zmniejsza i upraszcza się kod railsów i ten przez nie generowany.
Warto obejrzeć również plugin MinusMOR, który zmienia trochę podejście do javascriptu. Zamiast plików rjs, w których używamy rubiego zamienianego później na javascript, mamy pliki ejs, w których wpisujemy kod javascript z możliwością wstawiania kodu rubiego. Tak samo jak w rhtmlu poprzez <% %>.
W komentarzach apohllo zauważył, że plugin MinusMOR nie jest już rozwijany. Trzeba o tym pamiętać zaczynając go używać. Z drugiej strony widziałem kod pluginu i rejestruje on tylko nowe rozszerzenie “ejs”. Na początku szukane będą pliki z tym rozszerzeniem, a jeżeli ich nie będzie Railsy wyrenderują RJS. W każdym razie zaczynacie używać na własną odpowiedzialność. :)
Zapraszam do komentowania – prosiłbym o opinie dotyczące tego typu artykułów. Czy są zrozumiałe? Czy przydają się wam? Konstruktywna krytyka mile widziana. :)



	W tym miejscu trzeba zaznaczyć, że jest możliwość wygenerowania linku, czy formy, która będzie działała przy wyłączonym javascripcie, ale niewiele osób o tym wie i z tego korzysta. I trzeba dopisać 2 url, który z reguły jest taki sam – łamana jest zasada DRY



jQuery vs Prototype
2007-09-04T00:00:00-07:00
Kilka dni temu wrzuciłem notkę promującą jQuery. Często podczas porównywania narzędzi przeżywam pewien rodzaj euforii, która nie pozwala mi na obiektywne rozpatrzenie wszystkich za i przeciw. Przez chwilę wydaje mi się, że znalazłem narzędzie idealne (co oczywiście jest okropnym nadużyciem. jak ogólnie wiadomo idealny jest tylko polski rząd i jego sukcesy na przestrzeni ostatnich 2 lat – widziałem w reklamach).
W każdym razie ochłonąłem trochę i ze spokojem buddyjskiego mnicha (mówiłem już, że jestem oazą spokoju?) przetrząsnąłem cały internet w poszukiwaniu informacji. Próbowałem nawet wywołać flamewara na google groups. I biednie jest. Niewiele znalazłem. Wszędzie jakieś artykuły, których sens jest mniej więcej taki: “Przez długi czas używałem prototype(jQuery) i stwierdziłem, że muszę dać jQuery(prototype) szansę. jQuery jest prototype killerem!”. Nie licząc fajnego artykułu na agile ajax. Stety albo niestety autor nie do końca chce wyjawić, które podejście jest dla niego lepsze. Aczkolwiek pewną wskazówką może być przesiadka na jQuery, a nie odwrotnie.
No i krytyka modelu dziedziczenia zastosowanego w prototype.
Pozwoliłem sobie zrobić własne porównanie. Mam nadzieję, że chociaż w małym procencie obiektywne. ;-)
Manipulacja DOM i CSS
Na tym polu zdecydowanie wygrywa jQuery. Twórca zapewnił coś, co nazywa się “chainability”. Metody manipulujące elementami HTMLa można wywoływać w łańcuchach, na przykład jQuery('#some').show('slow').css('background-color', 'white').add('<p>Dodatkowy paragraf!</p>').
Jeżeli chodzi o same selektory, to od wersji 1.5.0 prototype ma obsługę selektorów CSS, więc nie ma już problemu z wybieraniem elementów w bardzo fikuśnych konfiguracjach ;-)
jQuery ma jeszcze jedną ciekawą właściwość. Wybrane elementy zawsze zwracane są w tablicy dzięki czemu biblioteka sama zadba o przeiterowanie po kolekcji i zaaplikowaniu metody do każdego jej elementu. Na przykład zamiast napisać (prototype):
$$('a').each(function(v, i) { Event.observe(v, 'click', fn); });


Możemy użyć:
jQuery('a').click(fn);


Wydajność
Na tym polu prototype mocno dawał w kość jQuery, ale sytuacja się poprawiła. W poprzednim poście zamieściłem 2 screeny, na których można zauważyć, że obecnie jQuery jest jakieś 2 razy wolniejsza (oczywiście jeżeli chodzi o same selektory). Dla innych metod podejrzewam, że będzie podobnie (dla each i map na pewno – jeżeli ktoś się bardzo nudzi może się pobawić i zrobić więcej benchmarków).
Ale statystyki na szczęście nie zawsze oddają to, co dzieje się w rzeczywistości. Jeżeli ktoś dysponuje odpowiednio wolnym komputerem (kilkaset mhz najlepiej), łatwo może sprawdzić, że efekty napisane w script.aculo.us bardziej “mulą” kompa niż ich odpowiedniki w jQuery (linux, firefox2 – wydaje mi się, że na innych systemach i przeglądarkach będzie podobnie). Szczególnie widać tą różnicę przy wszelakich tworach drag&drop.
Rozszerzenia
W tym miejscu wystarczy spojrzeć na listę rozszerzeń dla jQuery. Tego chyba nic w tej chwili  nie pobije. Rozszerzenia z zakresu UI dla prototypa (a właściwie script.aculo.us) wyglądają biednie w takim porównaniu.
Duży plus dla jQuery.
Społeczność
jQuery jest niewątpliwie biblioteką popularniejszą. Niektórzy mówią, że to chwilowy buzz (znowu ulegam modzie frameworkowej? :).
Prototype z kolei, chociaż mniej popularny, ma mocne wsparcie w społeczności RoR i wsparcie Rails Core Team. Podobno niektórzy pracują nad czymś co można nazwać “jQuery on Rails”, ale nadal prototype jako jedyny jest dostępny “out of the box”.
Rozszerzenia języka.
Prototype dodaje do javascriptu bardzo dużo metod, wzorowanych na metodach rubiego,  ułatwiających pracę z wbudowanymi typami. Między innymi moduł Enumerable, Hash, sporo metod do String, Date i dużo dużo więcej.
jQuery z kolei udostępnia tylko kilka metod (each, map, trim, grep…). Oczywiście można dodać swoje metody, ale w tym miejscu trzeba wspomnieć o filozofii jQuery.
Prototype dodaje nowe metody do poszczególnych klas, dzięki czemu można napisać na przykład:
['a', 'b', 'c'].each(function(v, i) { alert(v); });


W jQuery wyglądałoby to w ten sposób:
jQuery.each(['a', 'b', 'c'], function(v, i) { alert(v); });


Jeszcze nie jestem do końca pewien, które podejście mi bardziej pasuje. Być może połączenie jQuery z podejściem prototype?
jQuery.extend(Array.prototype, {
  each: function(iterator) {
    jQuery.each(this, iterator);
  }
});


I już można użyć konstrukcji analogicznej do prototype. Po paru zmianach można dodać też resztę funkcji z Enumerable – po odpowiednim przygotowaniu potrzeba niewiele więcej niż copy&paste. Podobnie łatwo będzie z resztą rozszerzeń.
Można również zostać przy podejściu jQuery i napisać metody działające mniej więcej tak:
jQuery.collect(arr, function(v, i) { /* jakiś kod */});


Chwilę po dodaniu tego posta przypadkiem trafiłem na fajny artykuł, który pokazuje dlaczego podejście a’la prototype jest po ciemnej stronie mocy ;-)
W następnym poście opiszę jak można to szybko, łatwo i przyjemnie zrobić. (o ile starczy mi czasu i samozaparcia)
Od wersji 1.6.0 prototype dostanie też parę bardzo przydatnych funkcji i narzędzi. Między innymi DOMBuilder, custom events, wrap() – bardzo podobają mi się takie smaczki. Więcej informacji w notce na stronie prototype
Podsumowując ten punkt, jeżeli chcemy intensywnie korzystać z wymienionych powyżej metod (polecam przejrzeć dokumentację prototype) lepszym wyborem będzie prototype. Z zaznaczeniem, że sporo z tych funkcji można bardzo łatwo przenieść do jQuery ;-)
Materiały
Przez pewien czas, dawno dawno temu, prototype nie miał prawie dokumentacji, co mogło niektórych zniechęcać. Aktualnie można powiedzieć, że zarówno prototype, jak i script.aculo.us są dobrze udokumentowane i raczej nikt nie będzie miał problemu z nauką. Tak samo zresztą jest z jQuery.
Oba framweorki doczakały się książek.

	jQuery:
	
		Learning jQuery
		jQuery Reference Guide
	
	prototype:
	
		Prototype and Scriptaculous in Action
		Prototype and script.aculo.us: You Never Knew JavaScript Could Do This!
	

Podsumowanie
Ciężko mi wybrać ten lepsiejszy framework. I na pewno wybór ten nie będzie obiektywny – każdy musi sam rozważyć czego oczekuje po bibliotece.
Wydaje mi się, że przy projekcie, który w tym momencie zaczynam bardziej sprawdzi się jQuery. Mam w głowie ułożony zaawansowany interfejs użytkownika i nie chciałbym żadnych zgrzytów, a jak pokazuje przykład scriptaculous, płynność różnych efektów nie ma wiele wspólnego z szybkością biblioteki.
Z drugiej strony jeżeli ktoś uważa, że będzie wykonywał po stronie użytkownika sporo obliczeń, pętli, działania na dużych tablicach itp. itd. prawdopodobnie dobrym wyborem będzie prototype – nie dość, że jest łatwiej wykonywać te czynności, to jeszcze wszystko działa szybciej.
Mam nadzieję, że powyższy opis pomoże w wybraniu biblioteki lepszej do rozwiązania danego problemu. Jeżeli pominąłem jakieś soczyste właściwości którejś z bibliotek proszę o komentarz – uzupełnię porównanie :)


Książki
2007-09-01T00:00:00-07:00
Zdarza mi się ostatnimi czasy przeczytać komentarz, że książki programistyczne są już niepotrzebne, bo i tak wszystko jest w necie. A nawet, cytuję: “w książkach to jest naćkane, jak chcesz konkretów to nie kupuj książek”.
Całkiem głupie to ;-)
Dla mnie książki programistyczne są niezastąpione. I najchętniej kupiłbym sobie połowę pozycji dostępnych na rynku. Po czym prawdopodobnie 1/3 bym nie przeczytał, ale to już inna kwestia. Ogólnie rzecz biorąc większości rzeczy zawartych w książkach można pewnie nauczyć się samemu, z lekką pomocą wujka Googla. Ale o ile przyjemniej przeczytać jak to robią profesjonaliści (o ile nikt nie da się nabrać niektórym profesjonalistom inaczej)
Po takim wstępie nie mogę się nie pochwalić, że jakiś czas temu kupiłem wspólnie z ludźmi od nowego projektu (na razie nie zapeszam. za jakiś czas pewnie coś napiszę) parę bardzo fajnych książek.

	Don’t make me think – genialna książka o usability. Bardzo krótka i treściwa. Autor starał się napisać książkę, którą będzie się dało przeczytać w parę godzin. I muszę przyznać, że bardzo dobrze mu to wyszło. Idealna dla ludzi, którzy nie są specami w tej kwestii, a chcą poprawić użyteczność swoich stron.


	Agile development with Rails – Pozycja obowiązkowa dla uczących się RoR. Co prawda teraz niewiele mi się przyda, ale czułbym się źle jakby jej nie kupił. Korzystałem dość sporo z ebooka z amule’a. No i przyda się bliźniemu, który właśnie zaczyna się uczyć RoR.


	Ruby for Rails – jeszcze nie przeczytałem, ale po przekartkowaniu zapowiada się bardzo ciekawie. Napiszę coś więcej jak wreszcie się za nią wezmę ;-)


	The Ruby Way – bardzo dobra książka. Jestem właśnie w trakcie czytania. Podaje bardzo dużo rozwiązań często spotykanych problemów zgddnie z “ruby way”. Ponad 600 stron esencji programowania ;-)


	JavaScript: The Definitive Guide – niektórzy narzekają, że książka bardziej zbliżona jest do dokumentacji niż do książki “do nauki”. Dla mnie to plus. Javascripta znam całkiem dobrze. Pewnie dzięki temu, że w poprzednim stuleciu, kiedy o bibliotekach takich jak jQuery nikt nie słyszał, bawiłem się w pisanie różnego rodzaju latających warstw, wysuwanych menu i innych arkanoidów (nawet fajnie się grało ;-). W tym momencie potrzebuję właśnie takiej dokumentacji, do której mogę spojrzeć podczas pisania i zobaczyć jakie metody udostępnia dana klasa, albo jak powinien się zachowywać jakiś kod. Jeżeli ktoś chce pisać coś więcej niż efekty z użyciem jQuery (czy innego script.aculo.us), to naprawdę zachęcam do kupna.

Podejrzewam, że gdyby początkujący programiści więcej inwestowali w wiedzę książkową to byłoby dużo mniej partactwa. Szczególnie, że książki związane z Rubim i RoR oprócz nauki programowania próbują od początku wpajać dobre praktyki programistyczne. I koniecznie trzeba przeczytać Pragmatycznego programistę :)


Dlaczego jQuery?
2007-08-31T00:00:00-07:00
Jako javascriptowego frameworka (z góry przepraszam ukrytych purystów językowych za brutalne wrzucanie spolszczonych angielszczyzmów – w razie czego proszę o wersję przetłumaczoną w komentarzu, trochę humoru zawsze się przyda) przez długi czas używałem zestawu prototype + script.aculo.us. Po krótkim czasie przywiązałem się i stwierdziłem, że nie ma sensu sprawdzać innych możliwości

	bo i tak większość frameworków oferuje podobne możliwości
	będę musiał stracić czas na nauczenie się czegoś nowego
	Ruby on Rails wspiera powyżej wymieniony zestaw

Właściwie to “wybranie” prototype’a było bezpośrednim następstwem ostatniego punktu. Pomyślałem, że skoro DHH wybrał ten framework, to coś w tym musi być. Podejrzewam, że w rzeczywistości było to spowodowane tym, że jQuery miał w tamtym okresie małą popularność (o ile w ogóle istniał). Patrząc na to jak wyglądają obie biblioteki można odnieść wrażenie, że filozofię dużo bliższą Railsom realizuje jQuery.
Najlepiej to widać patrząc na przykłady:
prototype:
  new Ajax.Updater('id', url, { method: 'get', parameters: par });
  var anchors = document.getElementsByTagName('a');
    for (var i=0; i<anchors.length; i++)
    {
        var anchor = anchors[i];
        var relAttribute = String(anchor.getAttribute('rel'));
        if (relAttribute.toLowerCase().match('history'))
        {
            Event.observe(anchor, 'click', function(){
              //siakaś funkcja
             });
        }
    }


jQuery:
  $('#id').load(url + par);
  $("a[@rel='history']").click(function(){
    //siakaś funkcja
  });


Od razu widać po której stronie stoi przejrzystość (i jasna strona mocy). Ten drugi przykład może nie być już aktualny, bo ostatnio programiści prototype wzięli się do roboty i co jakiś czas zamieszczają wiadomości o zmianach w API, ale takich kawałków można wkleić dużo więcej. Wszystko idzie w dobrą stronę, ale nie wiem czy uda się w niedalekiej przyszłości uzyskać lekkość jQuery.
Ruby on Rails niestety nie mają wsparcia dla jQuery, ale nie jest tak źle. Selektor elementów w RJS’ach dalej będzie działał, resztę kodu można wrzucać bezpośrednio poprzez `page <<`, a brak helperów? Możnaby je przepisać (i zapewne ktoś już to zaczął robić). Aczkolwiek pojawiają się głosy, że domyślne helpery w RoR są krnąbrne oraz złe. Po części całkiem słusznie. Z drugiej strony w niektórych aplikacjach nie ma sensu robić obsługi bez javascriptu (jakieś rozbudowane interfejsy użytkownika), a podobno używanie event handlerów jest wolniejsze niż zwykły onclick. Jak zwykle wszystko zależy od zastosowań i potrzeb. Ciężkie jest życie programisty. Kiedyś padnę na zawał od takiego nawału trudnych decyzji do podjęcia ;)
Jako dalszą lekturę polecam propagandę na blogu jQuery i doniesienia o nowej wersji, gdzie można podziwiać wyniki zabiegów optymalizacyjnych i sporo nowych mechanizmów. Całkiem niedawno jQuery doczekało się książki. Dużym plusem jest też ogromna ilość rozszerzeń. Lista wygląda imponująco.
Jedyne co mnie ostatnio zaniepokoiło to przesiadka z jQuery na prototype, o której mówi Zbigniew Sobiecki w wywiadzie. Jego doświadczenie widać najlepiej patrząc na blipa, więc jakieś powody musi mieć. Będę musiał to zbadać ;)
W każdym razie w tym momencie moim frameworkiem javascriptowym “of choice” jest jQuery. Jeżeli ktoś zna argumenty przemawiające za pozostaniem przy prototype i script.aculo.us niech się nie krępuje i zostawi komentarz.
Dopisane:

Znalazłem wczoraj fajne narzędzie do benchmarków. Niestety wersje bibliotek nie są najnowsze, co owocuje cienkimi wynikami jQuery, ale na szczęście jest link do źródeł, więc można wrzucić swoje wersje (ostatnie stabilne wersje jQuery i prototype). Jak widać na obrazkach twórcy jQuery włożyli ogromną ilość pracy w optymalizację, ale cały czas jeszcze trochę brakuje, żeby dogonić prototype.
Rozmawiałem wczoraj ze sztywnym na blipie (jest teraz jednym z developerów blipa). Zwrócił mi uwagę na parę rzeczy, które mi umknęły. Jedną z nich jest brak rozszerzeń dla obiektów istniejących już w javascripcie. Prototype udostępnia bardzo dużo metod, wzorowanych głównie na metodach rubiego, które ułatwiają pracę z typami wbudowanymi (wszelkie iteratory typu collect, each, any, all, różne metody dla klasy String, hashe itp. itd.). Szczerze mówiąc nawet nie pomyślałem, że nic podobnego nie ma w jQuery – przerzuciłem się dosłownie parę dni temu i nie pisałem nic większego. W takim momencie trzeba zadać sobie pytanie co jest priorytetem w danym projekcie. Oczywiście warto znać obie biblioteki, ale niestety do danego zadania trzeba wybrać jedną z nich (teoretycznie nic nie stoi na przeszkodzie, żeby załączyć obie, dzięki jQuery.noConflict, ale trzeba się liczyć z dodatkowymi kilobajtami).
Przejrzałem dodatkowo bloga prototypa i pojawia się cały czas sporo fajnych rzeczy. Myślę, że przy wyborze między tymi dwoma bibliotekami trzeba pomyśleć czy bardziej przydatne będą efekty wizualne i ogólnie grzebanie w CSS i DOM, czy stawiamy na pisanie różnych funkcji “niższego poziomu”. Najgorsze jest to, że wydaje mi się, że w projekcie, który zaczynam będzie się to rozkładało mniej więcej po połowie. Coś czuję, że wrócę jeszcze do tego tematu.


Kilka przydatnych linków
2007-08-25T00:00:00-07:00
Dawno nic nie pisałem, przez co mogło się niektórym wydawać, że blog umarł śmiercią naturalną. Bądź też ja umarłem (śmiercią niekoniecznie naturalną). Jak można dość łatwo zauważyć myśli o owych śmierciach (dwóch! chwila nieuwagi i sytuacja ociera się o żałobę narodową) były mocno przesadzone.
Na dobry początek reanimacji ledwo dychającego już blogusia tytułowe przydatne linki:

	Toggl – podczas pracy, szczególnie w domu, można bardzo łatwo zacząć zajmować się tysiącem rzeczy, które przerwą kodzenie. Toggl jest serwisem, który pozwala zmierzyć realny czas pracy. Dodaję nowy projekt, klikam “start” i zegar zaczyna tykać. I tyka tak sobie licząc godziny pracy. Od kilku dni takie liczenie pomaga mi bardzo w skupieniu nad pisaniem. Jak już chcę kliknąć na zakładkę z google readerem, to zaraz przychodzi myśl, że będę musiał przystopować toggl i realny czas pracy będzie dużo mniejszy.
	jQuery doczekało się kolejnej już wersji. Jak zwykle dużo nowych bajerów i jeszcze szybsze działanie (a po ostatnim “800% faster” myślałem, że dużo więcej nie wyciągną). Właściwie to na jQuery przesiadłem się dosyć niedawno i jako były-wielki-fan™ script.aculo.us czuję się zobligowany do napisania artykułu o tym co otworzyło mi oczy. Beware!
	Mashable przygotowało spis narzędzi do google readera. Wreszcie jakaś lista “x tools for…”, która mi się przydała. Polecam skin w stylu OS X. Naprawdę cieszy oko. Aż chce się zacząć przeglądać pomimo straszącego 100+

Na dzisiaj tyle. Oby to nie był ostatni post w przeciągu kolejnych kliku miesięcy. Trzymajcie kciuki.


Postanowienia na rok 2007
2006-12-31T00:00:00-08:00
A jakże ;-)

	napisać wreszcie i wypuścić jeden (może więcej?) z serwisów, na które mam pomysły. sporo tego jest, w większości serwisy niszowe i dość hermetyczne połączone z moimi zainteresowaniami. głównie na zasadzie: a gdybym tak miał możliwość…. (takie moje egoistyczne pobudki :) )
	uporządkować sprawy na uczelni (czyt. zaliczyć zaległe egzaminy, laborki, ćwiczenia)
	w kwestii nauki i poznawania nowych narzędzi:
	
		zostać guru w Rubim i Railsach ;)
		może Python i Django?
		Java – w stronę programowania na PDA itp.
		poznać lepiej JavaScript – żeby nie ograniczać się tylko do tego co oferują biblioteki typu Prototype/Scriptaculous, czy niezbyt wyrafinowane skrypty napisane przezemnie
		Google Maps
	
	wyremontować Misia Yogiego
	więcej czasu poświęcać bliskim :) (coś czuję, że ostatnio zaniedbuję znajomych bardziej niż zwykle)

Na razie nic więcej nie przychodzi mi do głowy. Pozostaje mi tylko życzyć wszystkiem szczęśliwego nowego roku :)


WAT on Rails
2006-12-07T00:00:00-08:00
W ramach pierwszego sympozjum CyberGuru na Wojskowej Akademii Technicznej w Warszawie wygłosiłem dzisiaj prezentację Przedstawienie framework'a Ruby on Rails. CeyberGuru skupia studentów, którzy chcą rozwijać swoje zainteresowania informatyczne. Do tej pory grupy wchodzące w skład CyberGuru były w większości mało aktywne, o ile w ogóle miały jakichś członków. Dość niedawno powstała inicjatywa odświeżenia owej organizacji, owocem której jest pierwsze (i mam nadzieję nie ostatnie) sympozjum.

Jeżeli chodzi o przebieg sympozjum to było bardzo przyjemnie. Wygłoszone prezentacje:
* Bezepieczeństwo aplikacji webowych, Krzysztof Wilkos
* Przedstawienie framework'a Ruby on Rails, Piotr Sarnacki
* Java w zastosowaniach wbudowanych, Andrzej Olszak
* Wprowadzenie do C# - Jakub Bańkowski

Wszystko nieco się przedłużyło - nie mamy dużego doświadczenia w orgaznizowaniu takich spotkań, więc prezentacje trwały dłużej niż zakładaliśmy. Uczestnicy sympozjum wypełnili ankiety, dzięki czemu będziemy wiedzieli co zmienić. Z tego co widziałem przydałoby się więcej przykładów, a mniej teorii. Prawdopodobnie będziemy dążyli wtedy do zmniejszenia liczby referatów podczas jednego sympozjum, co automatycznie wydłuży czas trwania pojedyńczego referatu.

Korzystając z okazji, po prezentacji, powiedziałem o swoim pomyśle stworzenia grupy webowej. Chciałbym zebrać ludzi zainteresowanych pisaniem i rozwijaniem aplikacji internetowych i rozpocząć pracę nad (bliżej jeszcze neisprecyzowanym) wspólnym projektem. Jedyne co na razie mogę powiedzieć na pewno - będziemy pisać używając Ruby on Rails. Jeżeli coś z tego wyniknie na pewno o tym napiszę.