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

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).

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.

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.

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.

Szalejące frameworki Rubiego i Rack/WSGI

Jarosław Zabiełło — Tue, 04 Mar 2008 22:56:00 +0100

Merb w wersji 0.9 poszedł na całość i oparli swój midleware na Rack’u. Jej twórcy nie kryją się że wzorowali się na pythonowej bibliotece WSGI. Biblioteka ta robi niezłą furorę w kręgach Rubiego. Powstaje sporo różnych mikroframeworków lub szybkich serwerów HTTP pracujących asynchronicznie i wykorzystujących Rack. Niedawno powstał świetny Thin, a już można przeczytać o 2x szybszy Ebb. Co ciekawe, Ebb chce docelowo obsługiwać zarówno frameworki Rubiego jak i Pythona! Jestem ciekaw czy będzie w stanie zdetronizować serwer Paste... Rack doczekał się już swojej implementacji w JRuby! Umożliwia to tym samym odpalanie w JRuby wszystkich frameworków które korzystają z Rack’a.

Frameworki

Rails – najważniejszy framework Rubiego, może być odpalany za pomocą Thina który używa Rack. Rails można odpalić na JRuby nawet prosto z Netbeans 6 :)
Merb – pretendent do detronizacji Rails, _używa Rack_i tym samym można go odpalić na JRuby.
Ramaze – podobnie do Merba, stara się promować bardziek elastyczne podejście, używa Rack, raczej nie zagrozi Merbowi
Fuzed – Rails z YAWS (szybkim serwerem HTTP napisanym w Erlangu)
Nitro – typu MVC z własnym ORM – Ogg i naciskiem na AJAX
IOWA – komponentowy,
Wee wzorowany na smalltalkowym Seaside używającym kontynuacji
Sinatra – mikroframework wzorowany na minimalistycznym, pythonowym Web.py
Camping – kolejny mikroframework w Ruby
Wave – wzorowany na Camping, też używa Rack i Rubiego wszędzie gdzie się da.
Invisible mikroframework używający Rack napisany w 35 linijkach kodu Rubiego (bardziej ciekawostka)

Mongrel i spółka

Webrick – serwer http dostępny razem ze standardową biblioteką Rubiego
Highperformance Webrick – szybsza wersja Webricka (używająca uniksowych forków)
Mongrel – klasyka, napisany częściowo w C, to od niego zaczęła się rewolucja i odejście od FastCGI jako metody odpalania Railsów.
Swiftyply i evented_mongrel asychroniczne, szybsze wersje Mongrela
Thin – asynchroniczny web server używający Mongrela i Rack
Ebb – używa Rack, większość kodu jest w C, dlatego jest taki szybki, na razie mało dokumentacji, być może następca Thin

Thin, unix sockets, Rails i Merb

Jarosław Zabiełło — Mon, 03 Mar 2008 03:36:00 +0100

Thin to szybki serwer HTTP służący do uruchamiania webowych frameworków napisanych w języku Ruby. Najbardziej z nich popularny jest oczywiście Rails. Choć istnieje wiele sposobów uruchomienia Railsów na serwerze produkcyjnym, użycie Thin wydaje się aktualnie najlepszym rozwiązaniem z przynajmniej dwóch powodów: zajmuje mniej pamięci i jest szybszy od popularnego Mongrela. Thin wykorzystuje dwa bardzo szybkie moduły: Mongel parser, Event Machine oraz (wzorowaną na pythonowym WSGI) bibliotekę Rack.

Od jakiegoś czasu Thin udostępnia uruchamianie klastra procesów wykorzystujący szybsze od TCP, sockety uniksowe. Zaletą jest nie tylko większa szybkość pracy, ale także odpada problem rezerwacji odpowiedniej liczby portów TCP.

Wygenerowanie pliku konfiguracyjnego polega na uruchomieniu w katalogu z projektem Rails (lub Merb) komendy:

thin config -C config/thin.yml -s4 -e production \
  --socket /tmp/thin_myapp.sock

Zostanie wygenerowany plik konfiguracyjny o mniej więcej takiej treści:

--- 
pid: tmp/pids/thin.pid
socket: /tmp/thin_myapp.sock
log: log/thin.log
max_conns: 1024
timeout: 30
chdir: /home/app/rails/myapp
environment: production
max_persistent_conns: 512
servers: 4
daemonize: true

Opcja -s4 oznacza że chcemy użyć 4 procesy. (W wypadku Nginksa, trzeba uważać na opcję max_persistent_conns, bo Nginx zdaje się nie ma jeszcze zaimplementowanej obsługi persistent connections. Najlepiej ją wyłączyć, tzn. przypisać jej wartość równą zeru. Apache powinien to obsługiwać. Z persistent connections wszystko powinno działać trochę szybciej.)

Aby to uruchomić, warto stworzyć plik startowy. Dla Debiana/Ubuntu należy stworzyć plik /etc/init.d/thin.rb (dla wygody napisalem to w Ruby zamiast Bashu):

#!/usr/bin/env ruby

require 'fileutils'
include FileUtils

def pids
  Dir.glob('tmp/pids/thin*.pid').map do |entry| 
    File.open(entry).read
  end
end

def start
  if pids.empty?
    rm_f "tmp/pids/thin*.pid"
    if File.exists? "config/init.rb" # start Merb
      system "thin start -r config.ru -C config/thin.yml"
    else # start Rails
      system "thin start -C config/thin.yml"
    end
  else
    puts "Thin cluster is already working"
  end
end

def stop
  if pids.empty?
    puts "Thin cluster is not working"
  else
    puts "Stopping thin cluster" unless pids.empty?
    pids.each {|pid| system "kill -TERM #{pid}" }
    rm_f "tmp/pids/thin*.pid"
  end
end

def restart
  stop
  sleep 1
  start
end

def status
  if pids.empty?
    puts "Thin cluster is not working"
  else
    puts "Thin cluster is working (pids: #{pids.join ', '})"
  end
end

if __FILE__ == $0
  opts = %w(start stop restart status)
  if opts.include?(ARGV[0]) and File.exists?(ARGV[1])
    Dir.chdir ARGV[1]
    eval ARGV[0]
  else
    print "Syntax: ruby {#{File.basename($0)} <#{opts.join '|'}}"
    puts  " /path/to/rails_or_merb/project"
  end
end

Należy dodać uprawnienia (sudo chmod a+x thin.rb) i ustawić aby domyślnie, podczas uruchomienia całego serwera był uruchamiany następujący skrypt (thin_myapp.rb) dla konkretnego projektu Rails lub Merb (komenda sudo update-rc.d -f thin_myapp.rb defaults).

#!/usr/bin/env ruby
path = '/path/to/rails-or-merb/project'

opts = %w(start stop restart status)
if opts.include? ARGV[0]
  system "/etc/init.d/thin.rb #{ARGV[0]} #{path}"
else
  puts "Syntax: #{File.basename(__FILE__)} {#{opts.join '|'}}"
end

W wypadku Merba trzeba pamiętać aby stworzyć dodatkowy plik konfiguracyjny config.ru (oczywiście dotyczy to Merba 0.9 lub nowszego):

# config.ru
Merb::BootLoader.run
run Merb::Rack::Application.new

Wyżej podany plik startowy rozpoznaje czy projekt to Rails czy Merb na podstawie odnalezienia pliku config/init.rb. Ale jak ktoś chce odpalać to ręcznie to Merba korzystającego z Thina i jego plikiu konfiguracyjnego (config/thin.yml) odpala się w taki sposób:

thin start -r config.ru -C config/thin.yml

Teraz wystarczy tylko ustawić load balancing do tak uruchomionego serwera. Dla serwera Nginx będzie to

upstream thin_myapp {
  server unix:/tmp/thin_myapp.0.sock;
  server unix:/tmp/thin_myapp.1.sock;
  server unix:/tmp/thin_myapp.2.sock;
  server unix:/tmp/thin_myapp.3.sock;
}

I w definicji serwera wirtualnego:

if (!-f $request_filename) {
  proxy_pass http://thin_myapp;
  break;
}

Zobacz też:

Update 2008-03-04:

Poprawiłem skrypt startowy tak aby był bardziej uniwersalny w wypadku używania wielu projektów Rails (lub Merb). Dodałem też informacje o możliwym problemie ze zmienną max_persistent_conns w wypadku Nginksa.

Merb 0.9 continious gem rebuilding

Jarosław Zabiełło — Wed, 20 Feb 2008 16:10:00 +0100

Niedawno opublikowane na RubyForge gemy Merb o wersji 0.9 wcale nie oznaczają że jest to wersje produkcyjna. Podobnie jak w wypadku Rubiego 1.9, twórcy Merba 0.9 określają tą wersję jako developerską. Jej celem jest wyczyszczenie błędów przed mająca nadejść wersją 1.0. Moim zdaniem nie ma sensu korzystać z gemów 0.9, lepiej od razu wskoczyć na wersję edge.

Frozen Merb

Kod Merb’a 0.9 został trochę podzielony na kilka mniejszych gemów. Celem takiego podejścia jest większa elastyczność. Mniejsza o to. Nowy gem gem-gen udostępnia skrypt zamrażający framdework. Należy w katalogu z projektem stworzyć katalog framework i tam zainstalować najnowszy kod rozwojowy. Trzeba mieć oczywiście zainstalowany system wersjonowania kodu – Git (port install git-core dla OSX, lub sudo apt-get install git-core dla Linuksa).

mkdir framework
cd framework
git clone git://github.com/wycats/merb-core.git
git clone git://github.com/wycats/merb-more.git

Wszystkie generatory są w Merbie realizowane przez skrypt merb-gen (oparty na gemie o tej samej nazwie). Jedną z opcji merb-gen’a jest możliwość stworzenia specjalnego skryptu który będzie odpalał gemy Merba z naszego katalogu framework zamiast z systemu. Skrypt można stworzyć za pomocą komendy.

merb-gen freezer frozen_merb

Od tej chwili można odpalać projekt za pomocą komendy script/frozen-merb. Dla wygody, podaję kod tasku rake’a aktualizującego biblioteki w katalogu framework. Kod jest prosty, przechodzi do podkatalogu i odpala komendę git pull.

desc 'Update all gits from frozen framework'
namespace :framework do
  task :update do    
    framework_path = File.join(Merb.root, 'framework')
    if File.directory?(framework_path)
      ['core', 'more', 'plugins'].each do |x|
        path = File.join(framework_path, "merb-#{x}")
        sh %{cd #{path}; git pull}
      end
    end
  end
end

Niestety, nie jest to rozwiązanie idealne, bo sam skrypt frozen-merb zakłada że mamy w systemie zainstalowany gem merb-core. Podobnie nie działają zadania Rake’a jeśliw systemie nie ma żadnych gemów Merba. Trochę to niekonsekwentne, bo część kodu korzysta z edge a część ze starszych gemów w systemie. Problem ten rozwiązuje zupełnie inny pomysł.

Continious gem rebuilding

W tym wypadku po prostu każda aktualizja kodu rozwojowego automatycznie przebudowuje gemy w systemie. Poniższy kod zadziała nawet jak w systemie nie mamy zainstalowanego ani jednego gemu Merba (z tego też powodu nie umieszczam go jako zadanie Rake’a) Skrypt należy skopiować do podkatalogu framework (choć można go lekko zmodyfikować aby działał z dowolnego katalogu). Cały kod sprowadza się do odpalenia od czasu poniższego skryptu.

#!/usr/bin/env ruby
%w(merb-core merb-more merb-plugins).each do |entry|
  puts "Updating git for #{entry}"
  system "cd #{entry}; git pull"
end
%w(merb-plugins/merb_* merb-more/merb-* merb-more merb-core).each do |entry|
  Dir.glob(entry).each do |dir| 
    system "cd #{dir}; rake repackage"
    system("sudo gem uninstall -a -i -x #{File.basename(dir)}") rescue Gem::InstallError 
    system "sudo gem install --no-rdoc --no-ri -f -l #{dir}/pkg/*"
  end
end

W tej metodzie nie musimy odpalać script/frozen-merb, wystarczy zwykła komenda merb. Powyższy skrypt dodałem do repozytorium Merba jako proponowane ulepszenie.

Najnowsza dokumentacja RDoc do merb-core umieszczona jest na http://blog.zabiello.com/merb-core/ (jest odświeżana co godzinę).

Merb 0.5

Jarosław Zabiełło — Thu, 10 Jan 2008 11:53:00 +0100

Konkurencja Railsów przyśpiesza. Ezra Zygmuntowicz i jego team wypuścili nową wersję Merb’a 0.5. Nowa wersja zawiera wiele usprawnień, w repozytorium została oznaczona jako “The big cleanup”. M.in. usprawniono współpracę z Hamlem za pomocą prekompilacji i szybszego includowania hamlowych partiali. Wbudowano wsparcie dla Sass dodają podkatalog sass w katalogu public. Przybyło też generatorów kodu, pozbyto się brzydkich stałych, itp., itd. Pojawiły się też nowe wersje gemów merb_datamapper, merb_sequel, merb_activerecord i merb_helpers. Nowa wersja Merba została nazwana “Thanks Zed” (w podziękowaniu dla Zeda Shaw, twórcy Mongrela)

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

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

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

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

PickAxe i inne książki

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

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

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

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

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

Rubinius, JRuby i Jubinius

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

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