Jarosław Zabiełło - BLOG

Agile 3 - jednak wyjdzie

Jarosław Zabiełło — Thu, 01 May 2008 20:15:00 +0200

Mimo, że wcześniej DHH niezbyt entuzjastycznie wypowiadał się na temat pisania kolejnej edycji bestseleru Agile Web Development in Rails, to jednak ugiął się pod ciężarem oczekiwań i trzecie wydanie będzie! Ci, co nie chcą czekać, mogą już teraz kupić PDF z wersją beta książki.

Jeśli autorzy będą jak zwykle opisywać wersję edge, to książka powinna opisywać mający wkrótce wyjść Rails 2.1.

Dobrą wieścią jest też to, że Ezra Zygmuntowicz, twórca konkurencyjnego Merba) postanowił ostatnio poświęcić trochę czasu aby ulepszyć kod Railsów. Najwyraźniej oba developerzy obu frameworków się nie zwalczają ale chcą ze sobą współpracować. Ezra dodał ostatnio ciekawy mechanizm do obsługi asynchronicznych adapterów Thin i Ebb, pozwalający na tworzenie oddzielnego wątku w wypadku gdy zapytanie jest długie (aby nie blokowała się asynchroniczna pętla).

Passenger mod_rails

Jarosław Zabiełło — Sat, 19 Apr 2008 05:31:00 +0200

Choć sam Rails jest intuicyjny i prosty w użyciu, to już sposób użycia go na serwerze produkcyjnym (gdzie liczy się głównie szybkość i stabilność) nie jest takie oczywiste z powodu istnienia wielu, alternatywnych rozwiązań. Powstały niedawno moduł dla Apache – mod_rails – może wszystko zmienić. Dzięki niemu uruchomienie Rails na serwerze staje się praktycznie tak samo trywialne jak w przypadku PHP i modułu mod_php!

Muszę przyznać, że początkowo byłem dosyć sceptycznie nastawiony do pomysłu mod_rails. Przede wszystkim, dziwnym wydawało się tworzyć moduł do Apache’a dla frameworka, czyli w sumie aplikacji, a nie dla samego języka Ruby. Niestety, istniejący od jakiegoś czasu mod_ruby był niedopracowany i krytykowany do tego stopnia że użycie go do Rails jest po prostu niezalecane. Dlatego od samego początku, gdy pojawił się Rails, promowano inne rozwiązanie (oparte na FastCGI). Pierwsze wydanie “Agile Web Development with Rails” jeszcze to promowało. W drugim wydaniu (wydanym również po polsku) autorzy przyznali że to rozwiązanie nie było wolne od szerego problemów. Na szczęście pojawił się Mongrel i bardzo szybko kombinacja szybkiego serwera HTTP z przodu + load balancing do klastera z mongreli stała się główną metodą używania Rails na serwerze produkcyjnym. I choć później pojawiły się jeszcze rozwiązania asynchroniczne (Swiftiply i evented_mongrel, Thin, Ebb), to zasadniczo niewiele wnosiły do rozwiązania standardowego poza trochę większą szybkością i innym (właśnie asynchronicznym) typem pracy.

Do tej pory sympatycy Ruby on Rails trochę smętnie poglądali na prostotę uruchamiania aplikacji “tego paskudnego pehapa” za pomocą modułu mod_php. To dzięki niemu PHP zdobył swoją popularność. Stworzenie prostej strony webowej stało się banalnie proste i nie wymagało dodatkowej wiedzy o load balancingu, ustawianiu buforowania, sposobie restartu klastera mongreli itp. Po prostu wrzucam plik i działa. Nawet sam DHH zaczął ostatnio wzdychać za taką prostotą uruchamiania aplikacji.

Stworzony mod_rails ma ambicję aby uruchomienie Railsów było tak proste jak to tylko możliwe. Z tego co mogłem sprawdzić, faktycznie działa to świetnie. Praktycznie nie jest wymagana żadna konfiguracja. Wystarczy raz ustawić Apache’a i można skupić się na budowaniu aplikacji. Domyślnie mod_rails uruchamia Rails w trybie produkcyjnym więc zmiana kodu wymaga przeładowanie aplikacji. Jednakże cała taka operacja sprowadza się do stworzenia pustego pliku restart.txt w podkatalogu tmp. Gdy Apache znajdzie taki plik, błyskawicznie przeładowuje pliki Rubiego i usuwa plik. Nie trzeba też zastanawiać się jak wyklucząć przetwarzanie plików statycznych i tworzonych przez mechanizm cache w RoR, mod_rails robi to automatycznie. Do tego zapewniona jest także ładna obsługa błędów. Po prostu wygląda to rewelacyjnie.

Jak z wydajnością? Jest całkiem nieźle. Autorzy twierdzą, że mod_rails jest trochę szybszy od thin’a. Mnie wyszło trochę odwrotnie, ale też nie robiłem zbyt drobiazgowych porównań. Nawet jeśli klaster serwerów thin czy ebb pracuje trochę wydajniej, to pokusa prostoty i wygody użycia mod_rails jest trudna do odparcia. Szkoda tylko, że mod_rails, jak sama nazwa wskazuje, pracuje tylko z Ruby on Rails. Dobrze by było, żeby później powstała podobna obsługa dla Merb’a (Choć Rails się także rozwija, Merb wciąż go mocno wyprzedza wydajnościowo. Tak z prostych testów mi wyszło, że potrafi być szybszy nawet 2-3 razy). Nie można jednak autorom mod_rails mieć przecież za złe, że poświęcili się najpopularniejszemu frameworkowi.

Passenger mod_rails to nie ostatnie słowo w sprawie deployingu Railsów. Podobną prostotą charakteryzuje się JRuby on Rails, ale o tym następnym razem.

Google App Engine

Jarosław Zabiełło — Sun, 13 Apr 2008 21:12:00 +0200

Od niedawna Google oferuje dosyć atrakcyjną możliwość pisania aplikacji webowych wykorzystujących potęgę ich infrastruktury – Google App Engine. Usługa jest darmowa i jeszcze testowa. Można stworzyć do 3 aplikacji z których każda może używać do 500MB danych trzymanych w BigTable i Google obiecuje że bez problemu będzie można uzyskać do 5 mln odsłon miesięcznie i niezły traffic 10 TB/m-c.

W tej chwili jedynym językiem dostępnym jest Python ale mają przybyć kolejne. Wykorzystywany jest WSGI. Dostępny jest też okrojony framework Django (nie można używać djangowego ORM’a ani wszystkich możliwości jakie dają djangowe szablony).

To co się bardzo zmienia, to podejście do bazy danych. Baza kolumnowa BigTable nie jest bazą relacyjną (nie istnieje tam pojęcie joinów). Trzeba więc trochę inaczej przemyśleć sposób tworzenia swoich danych. Pewnym problemem może być nie tylko uzależnienie od infrastruktury Google ale też trudność z późniejszym przeniesienia tak składowanych danych na inną platformę (choć istnieje z drugiej strony open-source’owy odpowiednik BigTable – HBase). W zamian jednak użycie platformy Google daje bardzo wysoką wydajność i odporność na błędy (jak padnie jeden serwer to jego pracę przejmuje automatycznie inny). Trochę nie jest dla mnie jeszcze jasne jak składować i usuwać dane z plikami statycznymi (obrazki, style kaskadowe, flash itp) skoro Google nie daje dostępu do systemu plików. Zablokowane są też sockety, wątki, używanie modułów napisanych w C, możliwość odpalania podprocesów, możliwości używania innych baz niż BigTable.

GitHub oficjalnie

Jarosław Zabiełło — Fri, 11 Apr 2008 01:38:00 +0200

Po okresie pilotażowym, GitHub wystartował oficjalnie. GitHub udostępnia wygodne zarządzanie projektami korzystającymi z Git’a – rozproszonego systemu wersjonowania kodu. Poza opcjami komercyjnymi jest dostępne darmowe konto dla projektów open source (tzn. nie można w nim trzymać prywatnych, zamkniętych repozytoriów, ale poza tym jest w wystarczająco funkcjonalne). Na Git’a migruje coraz więcej projektów. Poza Merbem i (wkrótce) Railsami, na GitHuba przeniosły się już: Haml, Ebb, JSpec, Capistrano, DataMapper itd.

Nadchodzi Rails 2.1

Jarosław Zabiełło — Thu, 03 Apr 2008 04:58:00 +0200

Jest bardzo bardzo niewiele książek opisujących aktualny stan Railsów 2.0.2 a już szykuje się kolejna wersja – 2.1 (nawet The Rails Way nie opisuje 2.0.2, ale tylko trochę z wersji edge, sprzed wydania 2.0) Jaką książkę nie zaczęto by pisać, staje się szybko nieaktualna. Co za czasy…

Zmian jest całkiem sporo, do ważniejszych należą różne poprawki w Active Record. Np. w końcu ma być możliwa selektywna aktualizacja wybranych kolumn (do tej pory AR, podczas zmiany jedneego atrybutu aktualizował je wszyskie w bazie) Co prawda tą funkcjonalność od dawna mają DataMapper i Sequel, ale dobrze że AR się wkońcu tu obudził.

article = Article.find(:first)
article.changed?  #=> false

# Zmiany poszczególnych atrybutów możliwe jest za 
# pomocą akcesora attr_name_changed?
article.title  #=> "Title"
article.title = "New Title"
article.title_changed? #=> true

# Jest też dostęp do poprzedniej wartości atrybutu 
# zapomocą akcesora attr_name_was
article.title_was  #=> "Title"

# Zobacz wcześniejszą i późniejszą wartość za pomocą
# akcesora attr_name_change
article.title_change  #=> ["Title", "New Title"]

# Zapis atrybutu wykonuje zapytanie dotyczące tylko jednej, 
# odpowiadającej mu kolumny w tabeli:
article.save
  #=>  "UPDATE articles SET title = 'New Title' WHERE id = 1"

Dodano też coś, co funkcjonalnie “od zawsze” było obecne w Sequel’u, SQLAlchemy czy Django ORM, mianowicie tu nazywa się to named scope (Rails wchłonęło popularny plugin has_finder pozwalając w końcu na łatwiejsze budowanie bardziej skomplikowanych warunków odpytywania bazy).

class User < ActiveRecord::Base
  named_scope :active, :conditions => {:active => true}
  named_scope :inactive, :conditions => {:active => false}
  named_scope :recent, lambda { { :conditions => ['created_at > ?', 1.week.ago] } }
end

# Typowe użycie:
User.active    # to samo co User.find(:all, :conditions => {:active => true})
User.inactive # to samo co User.find(:all, :conditions => {:active => false})
User.recent   # to samo co User.find(:all, :conditions => ['created_at > ?', 1.week.ago])

# Możliwe są w końcu kolejne zagnieżdżenia warunków:
User.active.recent
  # to samo co:
  # User.with_scope(:conditions => {:active => true}) do
  #   User.find(:all, :conditions => ['created_at > ?', 1.week.ago])
  # end

Autorzy Rails pozazdrościli Merbowi i dodali też możliwość ładowania gemów o konkretnej wersji (być może będzie to też początek końca pluginów w obecnej postaci i Rails pójdzie i tu ścieżką Merba?)

Rails::Initializer.run do |config| 

  # Załaduj najnowszą wersję haml
  config.gem "haml"

  # Załaduj konkretną wersję chronic
  config.gem "chronic", :version => '0.2.3'

  # Załaduj gem z repozytorium innego niż RubyForge
  config.gem "hpricot", :source => "http://code.whytheluckystiff.net"

  # Załaduj gem którego nazwa pliku jest inna niż nazwa gemu
  # Np. można załadować gem który potrzebuje require 'aws/s3' zamiast 
  # require 'aws-s3'
  config.gem "aws-s3", :lib => "aws/s3" 
end

Cieszy też, że poprawiono sposób działania buforowania oraz wbudowano lepszą obsługę dat i stref czasowych.

Ale z tego wszystkiego najbardziej mnie cieszy informacja inna informacja. Wspominałem o tym trzy dni temu, teraz zostało to oficjalnie ogłoszone: Rails migruje z Subversion na Gita. W końcu będzie można liczyć na poważniejsze przyśpieszenie prac i szybsze nanoszenie zgłaszanych poprawek (do tej pory to było tragicznie wolne, np. zgłoszony przeze mnie patch uwzględniono po 8 miesiącach). Rails, identycznie jak Merb, będzie używał tego samego serwera GitHub dla kodu i LightHouse. Więc ci, co nie mają tam kont, mogą już teraz o to zadbać. Praca z Git różni się też bardzo do SVN. Trochę przydatnych linków:

W komentarzach do newsu na stronie Railsów można znaleźć głosy rozczarowania tych, co używają system Windows. Woleli by aby wybrano bardziej multiplatformowy Mercurial, ale DHH uciął dyskusję mówiąc, że decyzja została już podjęta a kolejne wersje Rails będą i tak dostępne standardowo w gemach. Poza tym na razie Git może być od biedy używany pod Cygwinem i jest też projekt msysgit. No cóż, mnie to mało interesuje. Każdy wie, że windows i tak sucks i najlepiej pracuje tylko ze samym sobą. Rails ma zaś silniejsze związki z światem POSIX, dlatego najlepiej używać Ubuntu, Mac OS X czy innych systemów uniksowych. BTW, nowy Kubuntu 8.0.4 beta nawet nieźle śmiga na VMWare pod Win32. :)

Merb 0.9.2 - szybki start

Jarosław Zabiełło — Mon, 31 Mar 2008 01:09:00 +0200

Żyjemy w czasach przeładowania informacją. Większości ludzi nie chce się czytać dokładnych dokumentacji, czy kilkuset stronicowych książek. Nie dziwię się, że Rails spotkał się z entuzjastycznym przyjęciem ze strony osób zmęczonych walką z konfiguracją frameworków Javy czy chaosem i nieelegancją kodu PHP.

Merb pokazał że można jeszcze prościej i czytelniej niż zrobiono w Rails. To dobra informacja dla paranoików bojących się Railsów, którzy chcą czegoś bardzo prostego, aby nie musieć korzystać z PHP. I tu okazuje się, że Merb potrafi stworzyć sprawnie działający projekt prościej (i czytelniej) niż przykład użycia serwletu dostępny na stronie domowej Webricka. Merb jest też o wiele prostszy i bardziej intuicyjny niż pythonowe frameworki Django, Pylons czy TurboGears (nie mówiąc o pehapowych).

Najnowsza wersja stabilna Merba (0.9.2) jest dostępna normalnie w gemach. (Napisałem “stabilna”, mimo że formalnie jest to jeszcze wersja developerska, gdyż Ezra Zygmuntowicz uważa ją za wystarczająco dopracowaną aby móc używać do czegoś poważniejszego.) Instalacja jest więc standardowa:

sudo gem install merb

Merb w przeciwieństwie do Rails, używa jednego skryptu generatora kodu na wszystko – merb-gen (Rails używa skryptu “rails” oraz dodatkowych generatorow obecnych w katalogu scripts/). Standardowo można stworzyć trzy rodzaje projektów. Pełny, okrojony i minimalistyczny.

merb-gen app pelny
merb-gen app okrojony --flat
merb-gen app minimalny --very-flat

Zainteresowanym polecam porównanie sobie kodu wygenerowanego w każdym z trzech przypadków. Dla tych, co chcieliby minimum kodu, ostatnia opcja może być dosyć atrakcyjna.

Projekt minimalny

W wypadku użycia opcji --very-flat zostaną stworzone 2 (słownie: dwa) pliki. Jeden to README (z informacją, że całość odpala się za pomocą komendy: merb -I minimalny.rb), a drugi to kod Rubiego z całym frameworkiem. Załóżmy, że chcemy prosto przekazać parametry z URL do kontrolera. Wejście na stronę

http://localhost:4000/?a=test&b=tt

wyświetli w przeglądarce

Dostałem parametry: {"a"=>"test", "b"=>"tt", "action"=>"index", "controller"=>"minimalny"}

Cały kod frameworka sprowadzi się do jednego pliku:

Merb::Router.prepare do |r|
  r.match('/').to(:controller => 'minimalny', :action =>'index')
end

class Minimalny < Merb::Controller
  def index
    "Dostałem parametry: #{params.inspect}"
  end
end

Merb::Config.use { |c|
  c[:framework]           = {},
  c[:session_store]       = 'none',
  c[:exception_details]   = true
}

W praktyce oczywiście wygodniej jest używać pełnego projektu, bo daje wygodny dostęp do ORM, szablonów i wszystkich możliwości jakie oferuje Merb.

Projekt pełny – szybki start

Załóżmy, dla prostoty, że chcemy jakiejś bardzo prostej metody składowania danych i nie chcemy korzystać (przynajmniej na początku) z pełnych serwerów takich jak MySQL czy PostgreSQL. Doskonałym wyborem w takiej sytuacji będzie SQLite. Baza sprowadza się do jednego pliku, jest szybka i umożliwia korzystanie z języka SQL (włącznie z transakcjami). Instaluje się ją z gemow:

sudo gem install sqlite3-ruby

Tworzymy projekt:

merb-gen app myproj

Zostanie stworzony katalog myproj z różnymi plikami i katalogami w środku. To jest szkielet aplikacji i jest nawet prostszy od tego co generują Rails.

Domyślnie Merb nie zakłada, że chcemy korzystać z baz danych. Aby uaktywnić obsługę bazy danych, wejdź do pliku config/init.rb i odkomentować jedną linijkę z trzech dostępnych bibliotek zapewniających obiektowy dostęp do relacyjnej bazy danych: Active Record, DataMapper lub Sequel. Załóżmy, że wybraliśmy ten trzeci (mój ulubiony ze względu na prostotę i elastyczność; oczywiście zakładam, że wcześniej zainstalowaliśmy: sudo gem install sequel)

use_orm :sequel

Od tej chwili Merb będzie zakładał, że chcemy pracować z bazą danych za pomocą Sequela. To znacznie uprości to pracę z samą bazą SQLite i ułatwi ewentualne przepięcie aplikacji ze SQLite do MySQL czy innej bazy. Teraz przejdź do konsoli i odpal w katalogu projektu polecenie:

merb-gen

Merb już wie, że chcesz używać bazy, więc teraz automatycznie stworzy teraz plik konfiguracyjny config/database.sample.yml. Należy zmienić jego nazwę database.yml. Domyślnie tworzone są tam ustawienia dla MySQL. Aby użyć SQLite, zmień go na:

---
:development: &defaults
  :adapter: sqlite
  :database: baza.db
  :encoding: utf8

:test:
  <<: *defaults
  :database: baza-testowa.db

:production:
  <<: *defaults

Teraz stworzmy jakiś przykładowy model danych z użytkownikami i kontroler do ich zarządzania. Stwórzmy od razu cały zasób z obsługą REST.

merb-gen resource user

Teraz przejdź do pliku schema/migrations/001_user.rb i zmień go na

class UserMigration < Sequel::Migration
  def up
    create_table :users do
      varchar :name, :unique => true
      primary_key :id
    end
  end
  def down
    execute "DROP TABLE users"
  end
end

Będąc w katalogu projektu, odpal polecenie: uruchamiające “proces migracji:http://code.google.com/p/ruby-sequel/wiki/Migrations:

rake sequel:db:migrate

Zostanie stworzona baza (plik: baza.db) oraz tabela users. No to teraz trochę się pobawmy interaktywną konsolą aby dodać jakieś dane do bazy.

$ merb -i
 ~ Loaded DEVELOPMENT Environment...
 ~ loading gem 'merb_sequel' from  ...
 ~ Connecting to the 'baza.db' database on '' using 'sqlite' ...
 ~ Compiling routes...
 ~ Using 'share-nothing' cookie sessions (4kb limit per client)
User.create :name => 'Jarek'
=> #<User @values={:name=>"Jarek", :id=>1}>
User.create :name => 'Ewa'
=> #<User @values={:name=>"Ewa", :id=>2}>
User.all
=> [#<User @values={:name=>"Jarek", :id=>1}>, #<User @values={:name=>"Ewa", :id=>2}>]

OK. Ostatni krok. Otwórz plik app/views/users/index.html.erb i wstaw:

<p>W bazie mam użytkowników o imionach:</h1>
<% for user in @users %>
  <p><%= user.name %></p>
<% end %>

To wszystko! Odpal serwer z aplikacją za pomocą komendy: merb (więcej: merb --help) i otwórz stronę http://localhost:4000/users

Dodatkowe informacje

Ezra Zygmuntowicz zapowiedział intensywne prace nad stworzeniem zestawu manuali i dodatkowej dokumentacji dla Merba. Na razie musi wystarczyć to, co jest dostępne na stronie projektu plus informacje dostępne w blogach i na kanale IRC #merb serwera freenode.net. Powstaje też książka która jest dostępna w wersji roboczej przez PeepCode. API Merba jest dosyć przejrzyście opisane i co ważniejsze, przyjęto ścisłe zasady tworzenia dokumentacji, która były opisane wszystkie możliwe parametry dla każdej metody plus jakiś przykład użycia.

JRuby 1.1 final

Jarosław Zabiełło — Mon, 31 Mar 2008 00:51:00 +0200

Jest w końcu oczekiwana wersja stabilna JRuby 1.1. W chwili pisania tej notki, nie ma o tym jeszcze informacji na stronie głównej, ale jest już do pobrania. To bardzo dobra wiadomość, bo JRuby 1.1 już w wersjach rozwojowych był znacznie szybszy od poprzedniej 1.0, a w wielu testach bił wydajnością nie tylko Ruby 1.8.6 i 1.9, ale także Pythona 2.5.1. Dzięki JRuby webowe frameworki takie jak Rails czy Merb uzyskują pełny dostęp do bibliotek Javy i tym samym jakiekolwiek uwagi co do (nie)dojrzałości bibliotek Rubiego stają się nieistotne.

Wzmacnianie ekosystemu Rubiego - Merb

Jarosław Zabiełło — Sun, 30 Mar 2008 20:39:00 +0200

Przedwczoraj, w ramach MountainWest Ruby Conference 2008, miało miejsce ciekawe wystąpienie Ezry Zygmuntowicza na temat Merba, webowego frameworka stworzonego w języku Ruby. Wersja strumieniowa, pliki wideo oraz slajdy z wykładu, są do pobrania w internecie. Ezra w prosty sposób pokazał kilka interesujących cech Merba, które odróżniają go od konkurencyjnego Ruby on Rails.

Prostota jest lepsza od magii

Przede wszystkim, Merb zbudowano na założeniu że prostota jest lepsza od magii. Wiele osób nie znających zbytnio Rubiego, które zetknęły się z Railsami, myślą, że permanentnie magiczne (implicite) podejście do kodowania do jakaś integralna część samego języka Ruby. Tymczasem to nie jest problem Rubiego, ale filozofii zastosowanej w Rails. Sam Ruby (z założenia) pozwala na rozwiązanie tego samego problemu na bardzo wiele sposobow. W pełni zgadzam się z Ezrą, że operowanie na otwartych klasach Rubiego może być bardzo użyteczną techniką, ale z drugiej strony, nie powinna to być główna, ani najważniejsza, technika w arsenale narzędzi programisty Rubiego. W ostatecznym rozrachunku, łatwiej wrócić do kodu który jest prosty niż tylko ładny i magiczny z implementacją zaszytą głęboko w gdzieś includowanej bibliotece.

Ale Merb na tym się nie zatrzymuje. Jego mottem przewodnim jest nie ma szybszego kodu od braku kodu. Ezra nie zgadza się za bardzo z rozumowaniem prezentowanym przez DHH i Rails, że skoro czas programisty jest droższy od czasu serwera, to kto martwi się o wydajność, niech sobie dostawi… więcej serwerów. Nawiązuje to do permanentnie błędnej polityki ignorowania optymalizacji wydajnościowej w Rails na rzecz koncentrowania się na ciągle nowej funkcjonalności, “a wydajność poprawi się później, lub dostawi więcej sprzętu”. To prawda, że “przedwczesna optymalizacja jest korzeniem wielu problemów, komplikacji itp. itd” Prawdą jest jednakże i to, że “zbyt późna optymalizacja jest korzeniem wszystkich dodatkowych faktur do zapłacenia dla centrum hostingowego”. Merb od początku jest tworzony z uwzględnieniem wydajności, modularności, wielowątkowości i elastyczności.

Merb (licząc od wersji 0.9 która wnosi ogromne zmiany do wcześniejszej 0.5.x) został podzielony na kilka modułów. Rdzeń frameworka znajduje się w merb-core. Dodatkowe możliwości są dostępne w merb-more i merb-plugins. Nowy Merb jest zbudowany też na fundamencię Rack’a (wzorowanego na pythonowym WSGI, interfejsie dla aplikacji korzystających z protokołu HTTP). Merb może być uruchamiany z kilkoma serwerami: Ebb, asynchroniczny Mongrel (Evented Mongrel), FastCGI, wielowątkowy Mongrel (Merb, w przeciwieństwie do Rails, jest w pełni wielowątkowy), Thin czy Webrick.

Wielowątkowo czy asynchronicznie?

Ezra zwrócił uwagę na dosyć istotny aspekt wydajności dla adappterami asynchronicznymi (Ebb, Evented Mongrel, Thin) a wielowątkowym Mongrelem. Otóż nie zawsze adaptery asynchroniczne są szybsze. Tak jest tylko w wypadku krótko trwających zapytań. Jednakże jeśli mamy sytuację obsługi jakiegoś długiego (kilku sekundowego) requestu, to adapter asynchroniczny ma zablokowaną pętlę i w efekcie, jak to określił Erza, “pada na pysk”. Wielowątkowy Mongrel w takiej sytuacji, nie blokuje swojej pracy, ale odpala kolejny wątek dla obsługi następnych requestów. To, więc, co warto użyć zależy od charakteru aplikacji i można powiedzieć że wielowątkowy Mongrel jest najbardziej uniwersalnym, choć nie zawsze najszybszym, rozwiązaniem. Można ewentualnie mieszać podejścia i oczekiwane jako wolne, requesty kierować na Mongrela a resztę na Ebb, czy Thin. Osobiście tego jeszcze nie testowałem, ale wydaje się to rozsądnym podejściem.

Potężniejszy router adresów

Merb ma kompletnie inaczej napisany resolver adresów URL niż Rails. Po pierwsze, jest dużo szybszy ze względuna stosowaną prekompilację. Po drugie, jest dużo elastyczniejszy od Railsów (czy Django, gdzie który jest równie słaby). Przyjrzyjmy się poniższemu przykładowi.

Merb::Router.prepare do |r|
  r.match(%r[^/foor(.+)], :user_agent => /(MSIE|Gecko)/).
    to(:controller => "foo", :title => "[1]"),
       :action => "show", :agent => ":user_agent[1]")

  r.match("/bar/:baz").defer_to do |request, params|
    if bar = Bar.find_by_baz params[:baz]
      { :controller => bar.controller,
        :action => bar.action,
        :bar => bar.to_param }
    end
  end
end

W regule pierwszej widać, że router adresów zastosowany w Merbie pozwala filtrować po dowolnych nagłówkach. Np. może wiedzieć czy użyto przeglądarki Internet Explorer czy Firefox i stosownie do tego podejmuje dalsze działania. Drugi przykład jest jeszcze ciekawszy. Z adresu URL wyłuskiwana jest wartość którą Merb wykorzystuje aby odpytać bazę danych i na tej podstawie odpowiednio przekierować sterowanie.

Akcje o składni metod Rubiego

Mimo, że Merb pozwala, w podobny (do Rails) sposób, korzystać z hasza params, dodano tu trochę syntaktycznego lukru pozwalającego na pisanie kodu akcji w kontrolerze tak jak się pisze zwykłe metody w Rubim.

Merb.add_mime_type(:yaml, :to_yaml, %w[application/x-yaml text/yaml])
Merb.add_mime_type(:text, :to_text, %w[text/plain])
Merb.add_mime_type(:html, :to_html, %w[text/html application/xhtml+xml application/html])
Merb.add_mime_type(:xml,  :to_xml,  %w[application/xml text/xml application/x-xml], :Encoding => "UTF-8")
Merb.add_mime_type(:js,   :to_json, %w[text/javascript application/javascript application/x-javascript])
Merb.add_mime_type(:json, :to_json, %w[application/json text/x-json])      
#...
class Posts < Application
  provides :json, :yaml, :xml

  def show(id)
    @post = Post.find id
    display @post
  end

  def user(name="Jarek")
    only_provides :html
    @user = User.find_by_name name
  end
end

Przekazywanie parametrów w metodzie zamiast w haszu, moim zdaniem, znacznie zwiększa czytelność kodu. Umożliwia też wygodne stosowanie wartości domyślnych.

Słowo wyjaśnienia należy się metodzie display(). Merb w inny (od Rails) sposób rozpoznaje typ MIME przekazany do metody. Zamiast przekazywać w akcji blok do respond_to, Merb definiuje tylko jakie metody mają być wywołane dla odpowiedniego MIME. Np. akcja odpalana dla adresu /posts/user przekazuje do metody user hasz params o wartości {:name => "Jarek"}. Pobiera rekord z bazy i zwraca do klienta kod HTML wywołany za pomocą metody to_html na obiekcie user. W wypadku metody show zwracanych jest wiele różnych reprezentacji zależnych od użytego MIME.

Trzeba też dodać, że Merb nie używa żadnych magicznych railsowych metod render które mogą być wywołane tylko jeden raz (sic!) na request. Merb może kolekcjonować output z kilku miejsc. Zaś jeśli chodzi o samą akcję kontrolera, to zwracane jest po prostu ostatnie wyrażenie (tak, jak w zwykłych metodach Rubiego). Np. można otworzyć plik i zwrócić stworzony obiekt IO w metodzie kontrolera, a Merb potraktuje to jako przesyłanie strumieniowe.

Git rządzi

Ezra podkreślił sporo korzyści jakie dało przejście na rozproszony system wersjonowania kodu (Git). Znacznie łatwiej można eksperymentować z kodem i zgłaszać poprawki niż w wypadku starego SVN’a. I co ciekawe, także Ruby on Rails zamierza też przejść na Git’a w przeciągu jakichś dwóch miesięcu.

Merb 0.9.2 i Sake

Jarosław Zabiełło — Tue, 25 Mar 2008 07:11:00 +0100

Merb wchodzi w końcową fazę przed wydaniem wersji “1.0 (RailsConf)” . Właściwie nie zdziwiłbym się jakby lada dzień ta wesja wyszła bo prawie wszystkie tickety z problemami są już wyczyszczone. Rozproszony system wersjonowania kodu – Git – sprawdza się doskonale. Rozproszony Rake – Sake – także. Nowy Merb wspiera Ebb. Jest on szybszy od Mongrela, to najszybszy serwer HTTP dla Rubiego wykorzystujący interfejs Rack.

Sake, to Rake tylko, że działający zdalnie! Można plik z taskami dla Rake wstawić gdziekolwiek w internecie i każdy może go używać. Najlepiej zobaczyć to na przykładzie.

Stworzyłem w Githubie mini projekt merb-scripts gromadzącym różne wygodne zadania w kontekście Merba.

Sprawdzenie dostępnych zadań:

$ sake -T http://blog.zabiello.com/merb-scripts.sake
sake merb:pull         # Pull merb-core, merb-more, merb-plugins
sake merb:uninstall    # Uninstall all Ruby merb* gems
sake merb:juninstall   # Uninstall all JRuby merb* gems
sake merb:repackage    # Repackage merb-<core|more|plugins> (with all subgems)
sake merb:install      # Install all Merb gems and subgems
sake merb:jinstall     # Install all Merb gems and subgems for JRuby

Dodanie listy zadań do lokalnego repozytorium Sake (dokładniej: do pliku ~/.sake).

sake -i http://blog.zabiello.com/merb-scripts.sake
sake -T # pokaż nową listę zadań

Sprawdzenie źródła dla danej komendy:

sake -e merb:pull

desc 'Pull merb-core, merb-more, merb-plugins'
task 'merb:pull' do
  Rake::Task["merb:init"].invoke
  ["merb-core", "merb-more", "merb-plugins"].each do |dir|
    if File.exists?(dir) then
      sh("cd #{dir}; git pull")
    else
      sh("git clone git://github.com/#{@git_fork}/#{dir}.git")
    end
  end
end

Ściągnięcie najnowszej wersji rozwojowej Merba, kompilacja gemów i instalacja dla JRuby (musi być dostępny w systemie)

sake merb:pull merb:repackage merb:jinstall

Dla tych, co jeszcze nie wiedzą. Jest już dostępny JRuby RC3 i Merb może być uruchamiany pod JRuby tak jak i Rails.

Wolne odświeżanie gemów

Jarosław Zabiełło — Sun, 23 Mar 2008 17:57:00 +0100

Od jakiegoś czasu proces wielu użytkowników Leoparda narzeka na bardzo wolne odświeżanie gemów Rubiego. Instalacja nowego gemu potrafiła być 10x wolniejsza niż pod Ubuntu. Po małych modyfikacjach, ładowanie gemów na Leopardzie jest teraz dla odmiany szybsze niż na Ubuntu. :)

Przede wszystkim, wyłącz protokół IPv6 (System Preferences -> Network -> Advanced -> TCP/IP -> Configure IPv6) oraz dodać komendę

require 'resolv-replace'
# Ezra Zygmuntowicz radzi aby dodać:
Socket.do_not_reverse_lookup = true

do skryptu /opt/local/bin/gem (używam tu MacPortów). Tylko trzeba uważać, bo ta zmiana zniknie po gem update --system.

Jeśli ta zmiana nie wystarczy, to odpal komendę

sudo gem list -r -B 10000

i podmień plik /opt/local/lib/ruby/site_ruby/1.8/rubygems/remote_fetcher.rb na najnowszy z repozytorium.