rubedo -- alchemy_of :ruby, :rails

Benchmark: Ruby 1.8, Ruby 1.9, JRuby 1.3 RC2

2009-06-01T14:35:07-07:00

Wiele się mówi o szybkości Rubiego. Na pewno dzięki temu jest coraz mniej osób, które uważają, że jest to język zbyt wolny do aplikacji webowych - Merb w końcu pokazał, że potrafi być szybszy niż pythonowi konkurenci (Django, Pylons), a PHP (także pod względem wydajności frameworków) to już nie margines, a zwykła patologia.

Ostatnio modne są microbenchmarki, testujące pojedynczy aspekt języka - wyjątki, rekurencję itp. Jest to oczywista bzdura, która tak naprawdę niczego nie mówi, dlatego postanowiłem zmierzyć wydajność tych języków w czymś realnym.

Co na pokładzie?

C2D 2.4 GHz, 4GB RAM. System operacyjny: Mac OS X 10.5.7


$ ruby -v
ruby 1.8.6 (2008-08-11 patchlevel 287) [i686-darwin9.7.0]
Ruby Enterprise Edition 20090520
$ ruby19 -v
ruby 1.9.1p129 (2009-05-12 revision 23412) [i386-darwin9.6.0]
$ jruby -v
jruby 1.3.0RC2 (ruby 1.8.6p287) (2009-05-27 46598e4) 
(Java HotSpot(TM) 64-Bit Server VM 1.6.0_07) [x86_64-java]

Runda pierwsza: rozpoznawanie samogłosek w głosie ludzkim

Coś całkiem mocno wykraczające poza zwykłą pętlę for. Rozpoznawanie następuje oczywiście poprzez sztuczne sieci neuronowe, a konkretniej: wielowarstwowe perceptrony ze wsteczną propagacją błędów. Pomijając szczegóły implementacyjne (w końcu chodzi o wydajność), warto tylko zaznaczyć, że czas uczenia sieci został wydłużony do absurdalnej liczy setek tysięcy cykli uczenia się całkiem niemałej paczki danych treningowych. Wszystko po to, by JVM od JRubiego zdążyła się "rozgrzać" i pokazać pazurki. Jak ostre są te pazurki? Porównacie w testach wydajności poniżej:

Ruby 1.8

real    25m11.525s
user    25m6.682s
sys     0m1.949s

Ruby 1.9

real    12m39.138s
user    12m38.201s
sys     0m1.073s

JRuby

real    8m15.320s
user    8m12.577s
sys     0m4.128s

Tak jak się mówi w wielu miejscach, Ruby 1.9 jest dwukrotnie szybszy niż Ruby 1.8. Natomiast JRuby jest szybszy od Ruby 1.9 o 37%, co jest dość znaczną przewagą.

Runda druga: Rails

Nic wielkiego, testowana jest aplikacja z jedną akcją renderującą zwykły szablon. Nie używamy bazy danych. Całość serwowana przez pojedynczego Mongrela. W przypadku Ruby 1.9 należało wprowadzić parę zmian w kodzie C i .rb, aby rozszerzenie dało radę się skompilować. W przypadku JRubiego serwowanie aplikacji na Mongrelu jest, delikatnie mówiąc, nietypowe, ale potrzebne przy równych (w miarę miarodajnych) testach.

Parametr c mówi o ilości jednoczesnych połączeń podczas testów.

Ruby 1.8

-c 1: 582.73 [#/sec]
-c 5: 548.83 [#/sec]
-c 20: 524.57 [#/sec]

Ruby 1.9

-c 1: 548.06 [#/sec]
-c 5: 501.29 [#/sec]
-c 20: 476.33 [#/sec]

JRuby

-c 1: 365.03 [#/sec]
-c 5: 493.89 [#/sec]
-c 20: 486.92 [#/sec]

Bardzo dziwną rzeczą jest to, że Ruby 1.9 okazał się wolniejszy niż Ruby 1.8! JRuby delikatnie przewyższa 1.9 szybkością przy dużych obciążeniach, ale nadal jest to wolniej niż 1.8.

Runda trzecia: Merb

Typ aplikacji taki sam jak w przypadku Railsów. Pamiętajmy, że tylko Merb 1.1 (edge!) działa z wersją 1.9.

Ruby 1.8

-c 1: 953.38 [#/sec]
-c 5: 922.15 [#/sec]
-c 20: 915.56 [#/sec]

Ruby 1.9

-c 1: 1146.85 [#/sec]
-c 5: 1110.52 [#/sec]
-c 20: 1079.74 [#/sec]

JRuby

-c 1: 772.88 [#/sec]
-c 5: 1109.98 [#/sec]
-c 20: 1079.29 [#/sec]

Tutaj wyniki Ruby 1.9 i JRuby są porównywalne. Nie da się ukryć, że Merb jest lepiej napisany niż Railsy, dlatego im lepsza implementacja tym większy skok wydajności. Rails3 ma mieć ulepszone bebechy, dlatego możemy się spodziewać, że wydajność Rails 3 będzie porównywalna z Merbem.

Co to wszystko znaczy?

JRuby jest w pełni gotowy do produkcji i jest całkowicie kompatybilny (poza paroma gemami z rozszerzeniami w C) z wersją 1.8. Oznacza to mniej więcej tyle, że w większości przypadków, o ile mamy dużo RAM-u na naszym serwerze, możemy za darmo znacząco zwiększyć wydajność aplikacji zwyczajnie poprzez zmianę implementacji języka na Javową
JRuby 1.4 będzie jeszcze szybszy
Java 7 będzie posiadała w swoich bebechach wiele ficzerów, które ułatwiają tworzenie na jej bazie języków dynamicznych - oznaczać to będzie prawdopodobne wyrzucenie części kodu z JRubiego, bo będzie on już w samej platformie Java. Takie zabieg prawdopodobnie zwiększy wydajność JRubiego.
Tradycyjnie, nowa edycja Javy może zwiększyć jej wydajność, na czym skorzysta JRuby.
JRuby nie wymaga zgodności gemów z wersją 1.9, a daje porównywalny kop wydajnościowy, co wersja 1.9. Mam nadzieję, że te słowa nie zdemotywują nikogo do reimplementacji swoich bibliotek pod wersję 1.9... Więcej info na isitruby19.com.
Testy dotyczyły tylko trzech implementacji. Niedługo może się pojawić MagLev, Rubinius i MacRuby
MacRuby jest projektem wyjątkowo ciekawym. Docelowo ma być kompatybilny z każdym POSIXowym systemem (a więc nie tylko Mac OS X), a także rezygnować z wirtualnej maszyny YARV na rzecz LLVM. Będzie to olbrzymi kop wydajnościowy. Już teraz trunkowa wersja 0.5 potrafi być paręnaście razy szybsza od konkurentów, a skompilowany (tak jest, będzie można kompilować do binarki!) generator ciągu Fibonacciego jest szybszy niż... implementacja w Objective-C! Do tego dochodzi dojrzały generational garbage collector oraz obsługa natywnych wątków. Nie byle jaka implementacja!

nginx + Phusion Passenger™

2009-04-16T17:34:37-07:00

To nie jest spóźnione prima aprilis, aczkolwiek sam nie mogłem uwierzyć w to, co przeczytałem na blogu Phusion. Nie owijając w bawełnę, serwer nginx ma już pasażera. I to jakiego!

Instalacja jest tak prosta, jak obiecywano.

Niestety, kompilacja modułu wg. domyślnej konfiguracji wyłącza jawnie http_rewrite_module, nie działają także wyrażenia regularne (których także potrzebowałem w swojej konfiguracji, aby migracja była bezbolesna). Problemu jednak żadnego nie było, skompilowałem ręcznie nginksa z --with-pcre i paroma innymi modułami, nie wyłączając przy tym rewrite'ow - i wszystko poszło gładko. Zobaczymy, czy gładko będzie chodziło - bardzo dziwi mnie domyślne wyłączenie modułu przepisywania...

Tak czy inaczej, mój VPS już śmiga na nginx+passenger. A Wasz? :-)

Edytor WYSIWYG w adminie Django (newforms-admin)

2008-05-13T16:44:44-07:00

Pisząc systemy CMS, możemy się spotkać z powtarzającym się wymaganiem: ma być edytor WYSIWYG do tekstu. Widywałem aplikacje Django, w których główny admin był budowany na tym, co oferuje framework, a drugi - pisany ręcznie z edytorem WYSIWYG do większych tekstów. Zawsze jakieś rozwiązanie, ale da się lepiej. Jak?

Przede wszystkim: gałąź newforms-admin

Jeśli istnieje ktoś, kto jeszcze jej nie używa, niech zapozna się z jej opisem. W skrócie - bardziej elastyczny i podatny na własną rozbudowę admin budowany na bazie newforms.

Instalacja front-endu

Wybrałem FCKeditor, ze względu na duże możliwości i prostotę w implementacji, ale sposób działa dla dowolnie innego edytora. Należy ściągnąć paczkę i wrzucić ją tak, aby katalog z całością był dostępny pod ścieżką /fckeditor/. Tak jest domyślnie, ale nikt nam nie przeszkadza, by to zmienić, jeśli chcemy inaczej.

Drobna modyfikacja skryptu integrującego z Pythonem

Twórcy FCKeditora byli na tyle mili, by udostępniać go razem z pythonową klasą. Kopiujemy fckeditor.py do wybranego przez nas katalogu i przycinamy funkcje IsCompatible do takiej postaci:

def IsCompatible(self):
    return True

Widget dla newforms

Kod z Django snippets:

from django.newforms.widgets import Widget
from django.utils.safestring import mark_safe
from django.utils.encoding import force_unicode
import myapp.core.fckeditor as fck
# ........
class FCKeditor(Widget):
   def __init__(self, attrs=None):
           if attrs is not None:
                   self.attrs = attrs.copy()
           else:
                   self.attrs = {}

           self.__widget = fck.FCKeditor("FCKeditor1")
           super(FCKeditor, self).__init__(attrs)

           self.setAtters(self.attrs)

   def setAtters(self, attrs):
           if attrs is None:
                   return

           if 'basepath' in attrs:
                   self.__widget.BasePath = attrs['basepath']

           if 'width' in attrs:
                   self.__widget.Width = attrs['width']

           if 'height' in attrs:
                   self.__widget.Height = attrs['height']

           if 'toolbar' in attrs:
                   self.__widget.ToolbarSet = attrs['toolbar']

   def render(self, name, value, attrs=None):
           if value is None: value = ''
           value = force_unicode(value)

           self.__widget.InstanceName = name
           self.__widget.Value = value
           self.setAtters(attrs)

           final_attrs = self.build_attrs(attrs, name=name)
           return mark_safe(self.__widget.CreateHtml())

Podczepienie widgetu do modelu

W moim przypadku jest to model Clip, zmieniam formularz dla textfield-u description:

class ClipOptions(admin.ModelAdmin):
        # .........
        
        def formfield_for_dbfield(self, db_field, **kwargs):
                if db_field.name == 'description':
                        kwargs['widget'] = FCKeditor
                return super(ClipOptions,self).formfield_for_dbfield(db_field,**kwargs)

# ...
global_admin = admin.AdminSite()
global_admin.register(Clip, ClipOptions)

Gotowe

Oto jak wygląda w realnej aplikacji:

Translashun gem... iz translating

2008-03-10T12:48:35-07:00

Dave Dribin wypuścił gema, na którego wszyscy czekali i nawet o tym nie wiedzieli.

Gem nazywa się LOLspeak i jak nietrudno się domyślić, umożliwia tłumaczenie zdań z języka normalnego na lolcatowy. Użycie jest bardzo proste:

gem install lolspeak

require 'rubygems'
require 'lolspeak'

puts "hi cat, i have something for you".to_lolspeak
#               oh hai kitteh, i has somethin 4 u

Słownik zapewne będzie szybko i intensywnie rozbudowywany, tak więc jeśli planujesz internacjonalizację swoich rubinowych aplikacji, pamiętaj, że kot też człowiek.

RuPy - Ruby & Python Conference

2008-01-26T10:59:01-08:00

Konferencja RuPy 2008, która odbędzie się 12-13 kwietnia 2008 r., w Poznaniu to już druga konferencja poświęcona językom programowania Python i Ruby. Pierwszy raz odbyła się w kwietniu 2007 r. Doszło wówczas do spotkania entuzjastów tych technologii z Polski i innych krajów. Ta pierwsza konferencja nie była dużym przedsięwzięciem, ale okazała się ogromnym sukcesem i wartościowym doświadczeniem zarówno dla uczestników jak i prelegentów. Zachęceni tych faktem, organizatorzy w tym roku celują w wydarzenie o jeszcze większej skali.

Komitet organizacyjny konferencji RuPy 2008 poszukuje prelegentów chętnych wygłosić referat dotyczący języków Python i Ruby. Jeśli macie jakieś interesujące pomysły, nie zwlekajcie i wyślijcie e-maila ze swoją propozycję złożoną z tytułu referatu, krótkiego opisu zagadnienia oraz kilku słów o sobie pod adres: talks@rupy.eu. Dla zaproszonych prelegentów oferowane są darmowe zakwaterowania i wyżywienie oraz możliwość poznania bardzo energicznej społeczności IT. Zachęcamy ponadto wszystkich do uczestnictwa w dodatkowych atrakcjach przygotowanych przez organizatorów konferencji. Zeszłoroczne 'Geek party' dla wielu było niezapomnianym wrażeniem. Macie również możliwość także wspierać inicjatywę RuPy poprzez propagowanie adresu strony konferencji i informacji o niej.

Osoby chętne do wygłoszenia referatu proszone są do nadsyłania propozycji na powyższy adres w terminie do końca stycznia 2008!

Więcej informacji o konferencji na stronie: http://www.rupy.eu

Zed Shaw: "Rails Is A Ghetto"

2008-01-06T05:47:01-08:00

Każdy programista Rails zna to nazwisko. Twórca Mongrela postanowił odejść ze społeczności, pozostawiając jako uzasadnienie bardzo długi, ale interesujący post.

Z miejsca ostrzegam, że post jest cieżki, napisany ciętym językiem. Ujawnia smutne fakty i historie, które miały miejsce w społeczności, również wśród core developerów Railsów. O krytykę Rubiego także nietrudno. Lektura dość przykra dla zwolenników Rails.

When I hang out with the Nitro, Factor, Django, Lua, Python, Lisp, or Mongrel crews I get to talk to super smart guys who have egos for sure, but have mutual respect. They craft nifty shit I love to play with, are fun to talk with even when I disagree, and don’t say mean shit when I’m not around.

With Rails I get scrawny cocksuckers with carpal tunnel syndrome talking to me like they’re gonna eat my young. Their feeble PHP infected minds can’t grasp advanced shit like objects or closures. When you combine stupid businesses with stupid people using a stupid framework based on a big fat fucking lie on a shitty platform you get the perfect storm of dumbfuck where a man like me can’t find work.

Po paru dniach od napisania artykułu, autor otrzymał ponad 400 maili. Na ich podstawie będzie pisał FAQ, tak więc kto myśli, że sprawa cichnie, ten się myli...

Zdaję sobie sprawę, że większa część polskiej społeczności zdążyła się już zapoznać z całym postem, ale bardzo ciekawi mnie jak Wy widzicie tę sprawę. Prosiłbym tylko o język choć minimalnie ładniejszy niż ten, którego użył Zed ;-).

Obiekty w Rubim, część 2: singletony, moduły, miksiny

2007-10-28T17:20:48-07:00

W tej części kursu omówimy wzorzec singletonu, dynamicznie dodawane metody oraz moduły i miksiny w języku Ruby.

Wzorzec singletonu

Założenia są proste: dana klasa może występować w co najwyżej jednym egzemplarzu.

Stwórzmy dla przykładu klasę implementującą konsolę - taką, jaką znamy choćby z Quake'a. Ponieważ w całym silniku gry nie potrzebujemy więcej, niż jednej konsoli - zastosujemy tutaj wzorzec singletonu:

class Console
  def self.instance
    return @@instance if defined? @@instance
    @@instance = new
  end
  
  private_class_method :new, :allocate
end

c1 = Console.instance
c2 = Console.instance

c1.object_id    # => 22691800
c2.object_id    # => 22691800

Widać tutaj, że aby zrealizować singleton w Rubim, należy:

zablokować metody new i allocate - uczynić je prywatnymi, by mogły być wywoływane tylko w odrębie klasy
udostępnić metodę, która zwraca (a wcześniej ewentualnie tworzy) instancję naszego singletonu

Oczywiście Ruby nie byłby sobą, gdyby nie pozwolił nam na realizację tego wszystkiego za pomocą paru stuknięć w klawiaturę :-).

require 'singleton'

class Console
  include Singleton
end

c1 = Console.instance
c2 = Console.instance

c1.object_id    # => 22691800
c2.object_id    # => 22691800

Metody singletonu

Nazwa może być nieco myląca, gdyż nie do końca jest związana ze wzorcem singletonu.

Ruby pokazuje swoją dynamikę w przykładzie, w którym rozszerzamy wbudowaną w język klasę:

class Integer
  def odd?
    (self % 2) == 1
  end
end

puts 5.odd?       # => true
puts 6.odd?       # => false
puts 7.odd?       # => true

To nie koniec, można posunąć się nawet dalej. Ruby oferuje nam możliwość dopisania metody do egzemplarza dowolnej klasy. Taką metodę nazywamy metodą singletonu.

class Dog
  def bark
    puts "Woof, woof!"
  end
  
  def method_missing(name)
    puts "Hey, man. I can't #{name}!"
  end
end

Rex, Azor = Dog.new, Dog.new

def Azor.kill
  puts "/me is killing"
end

Rex.kill
Azor.kill

Hey, man. I can't kill!
/me is killing

Metoda method_missing wywoływana jest w momencie, gdy następuje próba wywołania nieistniejącej metody. Więcej takich sztuczek postaram się omówić w kolejnej części tutoriala.

Przestrzenie nazw

...czyli gdy klasa niezbyt dobrze modeluje problem.

Przestrzenie nazw to jedno z dwóch zastosowań modułów (o drugim powiemy za chwilę) w Rubim. Poza umożliwieniem programiście logicznej organizacji struktury projektu, pozwalają dodatkowo uniknąć konfliktów nazw, które tak bardzo potrafią dokuczać w innych językach. O przykłady nietrudno. log(10) może oznaczać zarówno logarytm z dziesięciu, jak i zalogowanie błędu o kodzie 10. Takich niejednoznaczności należy unikać.

Jak?

module MyMath
  # ...
  def self.log(x)
    # ...
  end
end

module CriticalErrorLogger
  def self.log(error_num)
    # ...
  end
end

y = MyMath.log(10)                      # Logarytm
CriticalErrorLogger.log(10)             # Logowanie błędu

Pamiętajmy, że konieczne jest poprzedzenie selfem nazwy metody, by zdefiniować metodę modułu, a nie instancji. Metody instancji mają zastosowanie w miksinach, o których dosłownie za chwilę.

Czasem jednak chcemy napisać program czysto matematyczny, a wtedy rzeczą naturalną jest, że sinus to sin(x) a nie Math.sin(x):

puts Math.sin(Math::PI/2)

include Math
puts sin(PI/2)

Widać tutaj, że includowaniu ulegają nie tylko metody, ale także stałe.

require

Chcąc użyć klas i metod z zewnętrznego pliku, konieczne jest użycie metody require (np. require 'complex' - jeśli chcemy użyć w programie liczb zespolonych). Jak widać, nie ma potrzeby pisania rozszerzenia ładowanego pliku.

A ścieżki?

Są, wszystkie dostępne w magicznej zmiennej $:

irb(main):001:0> $: => ["c:/ruby/lib/ruby/site_ruby/1.8", "c:/ruby/lib/ruby/site_ruby/1.8/i386-msvcrt", "c:/ruby/lib/ruby/site_ruby", "c:/ru by/lib/ruby/1.8", "c:/ruby/lib/ruby/1.8/i386-mswin32", "."

Tablica (a raczej kobyła) z plikami, które includowaliśmy (wiednie lub bezwiednie) dostępna jest pod magiczną nazwą $"

irb(main):002:0> $" => ["rbconfig.rb", "rubygems/rubygems_version.rb", "thread.so", "thread.rb", "rbconfig/datadir.rb", "rubygems/user_inter action.rb", "socket.so", "timeout.rb", "net/protocol.rb", "uri/common.rb", "uri/generic.rb", "uri/ftp.rb", "uri/http.rb" , "uri/https.rb", "uri/ldap.rb", "uri/mailto.rb", "uri.rb", "net/http.rb", "stringio.so", "yaml/error.rb", "syck.so", "y aml/ypath.rb", "yaml/basenode.rb", "yaml/syck.rb", "yaml/tag.rb", "yaml/stream.rb", "yaml/constants.rb", "rational.rb", "date/format.rb", "date.rb", "yaml/rubytypes.rb", "yaml/types.rb", "yaml.rb", "zlib.so", "rubygems/remote_fetcher.rb", " forwardable.rb", "digest.so", "digest.rb", "digest/sha2.rb", "parsedate.rb", "time.rb", "rubygems/source_index.rb", "rub ygems/version.rb", "rubygems/specification.rb", "openssl.so", "openssl/bn.rb", "openssl/cipher.rb", "openssl/digest.rb", "openssl/buffering.rb", "fcntl.so", "openssl/ssl.rb", "openssl/x509.rb", "openssl.rb", "rubygems/gem_openssl.rb", "ruby gems/security.rb", "rubygems/custom_require.rb", "rubygems.rb", "ubygems.rb", "e2mmap.rb", "irb/init.rb", "irb/workspace .rb", "irb/context.rb", "irb/extend-command.rb", "irb/output-method.rb", "irb/notifier.rb", "irb/slex.rb", "irb/ruby-tok en.rb", "irb/ruby-lex.rb", "readline.so", "irb/input-method.rb", "irb/locale.rb", "irb.rb"]

Ups...

Metoda require powoduje załadowanie pliku docelowego tylko raz. Niestety, przed nieopatrznym powtórzeniem procesu Ruby broni się niezbyt mądrze.

irb(main):001:0> require 'mathn'
=> true
irb(main):002:0> require 'mathn'
=> false
irb(main):003:0> require 'C:/ruby/lib/ruby/1.8/mathn.rb'
C:/ruby/lib/ruby/1.8/mathn.rb:118: warning: already initialized constant Unify
C:/ruby/lib/ruby/1.8/mathn.rb:306: warning: already initialized constant Unify
=> true

W tym przypadku wygląda to niewinnie, ale bardzo łatwo można sobie zrobić tym krzywdę. Prawdopodobnie zostanie to poprawione w przyszłych wersjach, ale póki co - beware!

Miksiny

Drugie zastosowanie modułów. Wspaniała możliwość będąca doskonałym połączeniem zalet dziedziczenia wielobazowego (znanego chociażby z C++) z przejrzystością i jednoznacznością definicji klas.

Prześledźmy poniższy przykład:

module Witness
  def create_witness
    @witness = "Been there. Seen it. Got the scars."
  end
  
  def has_witness?
    (defined? @witness) ? true : false
  end
end

class Accident
  include Witness
  
  def to_s
    "An accident with " + (self.has_witness? ? 
            "a witness saying \'#{@witness}\'" : "no witness")
  end
end

acc1, acc2 = Accident.new, Accident.new
acc2.create_witness

puts acc1, acc2

An accident with no witness
An accident with a witness saying 'Been there. Seen it. Got the scars.'

Jak to wszystko funkcjonuje?

moduły nigdy nie mają instancji - mogą co najwyżej zostać włączone do klasy; wywołać można jedynie metody modułu (np. Math.sin(0)
argumentem metody include jest zawsze nazwa widocznego z danego miejsca modułu; jeśli moduł nie jest widoczny, należy załadować odpowiedni plik za pomocą metody require
klasa, do której dołączany jest moduł, przejmuje także jego zmienne instancji, modułu oraz stałe

Pamiętać należy o kolejności poszukiwania metody w momencie wywołania:

metody oryginalnej klasy
metody wmiksowane
metody przodka
metody wmiksowane w przodka

Oczywiście w momencie znalezienia metody, jest ona wywoływana, a samo przeszukiwanie przerywane.

Rubinowe miksiny

Ruby dostarcza parę ciekawych modułów, które wmiksowane są w wiele standardowych klas. Tylko czekają, aż wmiksujemy je i my :). Na przykładzie omówimy Comparable i Enumerable.

Enumerable

Zasada jest prosta. Implementujemy w naszej klasie metodę each, a Ruby zajmuje się resztą. Znaczy się: dopisuje za nas takie metody, jak all?, any?, map, min, sort itp. (ri Enumerable!).

Dla przykładu zaimplementujmy kolekcję, która zawiera ciągi kropek. Ilość kropek kolejnych elementów jest równa wartości kolejnych elementów tablicy podanej do konstruktora.

class Dotter
  include Enumerable
  
  def initialize(val)
    @collection = val.to_a
  end
  
  def each
    @collection.each { |e| yield '.'*e }
  end
  
end

d1 = Dotter.new(2..7)
# ..
# ...
# ....
# .....
# ......
# .......

d2 = Dotter.new([5, 4, 6, 1, 7, 3])
# .....
# ....
# ......
# .
# .......
# ...


d1.all? { |v| v.length > 8} # false
d2.any? { |v| v.length%2}   # true
d2.include?('..')           # false
d2.max                      # "......."
d2.min                      # "."
d2.sort                     # [".", "...", "....", ".....", 
                            # "......", "......."]

Comparable

Użycie tego modułu jest równie proste. Implementujemy metodę <=>, a w efekcie otrzymujemy metody porównania oraz between?.

Dla przypomnienia, metoda <=> zwraca -1, gdy pierwszy element jest mniejszy od drugiego, 0 - gdy oba elementy są równe oraz 1, gdy pierwszy element jest większy od drugiego.

Czas na praktykę. Weźmy przykład z dokumentacji Rubiego. Poza tym, że rozmiar jednak ma znaczenie, jeszcze coś innego jest w nim interesujące.

class SizeMatters
  include Comparable
  
  attr :str
  def <=>(anOther)
    str.size <=> anOther.str.size
  end
  
  def initialize(str)
    @str = str
  end
  
  def inspect
    @str
  end
end

s1 = SizeMatters.new("Z")
s2 = SizeMatters.new("YY")
s3 = SizeMatters.new("XXX")
s4 = SizeMatters.new("WWWW")
s5 = SizeMatters.new("VVVVV")

s1 < s2                       # => true
s4.between?(s1, s3)           # => false
s4.between?(s3, s5)           # => true
[ s3, s2, s5, s4, s1 ].sort   # => [Z, YY, XXX, WWWW, VVVVV]

Czy wiesz, że...

Gdy zdefiniujemy pustą klasę:

class Empty
end

e = Empty.new
puts e.methods.sort.join(", ")

==, ===, =~, __id__, __send__, class, clone, display, dup, eql?, equal?, extend, freeze, frozen?, gem, hash, id, inspect, instance_eval, instance_of?, instance_variable_defined?, instance_variable_get, instance_variable_set, instance_variables, is_a?, kind_of?, method, methods, nil?, object_id, private_methods, protected_methods, public_methods, require, require_gem, respond_to?, send, singleton_methods, taguri, taguri=, taint, tainted?, to_a, to_s, to_yaml, to_yaml_properties, to_yaml_style, type, untaint

zauważamy sporą ilości metod, których nie definiowaliśmy. Tak naprawdę są to metody klas nadrzędnych do naszej: Object, Module, Class.

Za to zamieszanie Ruby jest krytykowany przez wielu sceptyków. Okazuje się, że może być jeszcze gorzej :).

module Kernel
  def are_you_there?
    "Yeah, fuc*in' everywhere!"
  end
end

5.are_you_there?        # "Yeah, fuc*in' everywhere!"
"test".are_you_there?   # "Yeah, fuc*in' everywhere!"

Publiczna metoda modułu Kernel jest wmiksowana w każdą klasę. Zdefiniowanie metody poza jakąkolwiek klasą definiuje ją w module Kernel. Includowanie modułu poza jakąkolwiek klasą powoduje inkludowanie go do modułu Kernel.

Podany wyżej przykład pokazuje skalę tego, co dopiszemy do Kernela. Niby nic... ale nie bawmy się w Lenina!

Zabawa w języki i skojarzenia :)

2007-10-13T14:18:19-07:00

Radarek wymyślił zabawę w języki i skojarzenia. Zasady są proste: do pewnych popularnych języków dopisujemy skojarzenia, zarówno te pozytywne, jak i negatywne. Let Mortal Kombat begin!

Język	Pozytywy	Negatywy
PHP	dobry na stronę domową, znalazłem go nawet w konserwie	wymusza siłą fizyczną burdel w kodzie
Java	dorobek, enterprise, powaga	hello world: piszę do tego 3 frameworki, 1254 linie konfiguracji w XML-u i obsługę 23 WyjątkówOCholernieDługichNazwach; smutni niewyspani programiści; Eclipse wolno działa!
Pascal	mój prawie pierwszy język, sentyment, przejrzystość	DJ Ango wylał go do zlewu :(
C	dzieciństwo, szybki, prawie zwięzły	prawie zwięzły, "krwa, ten kod musi* działać!"
C++	szybki, new + delete, obiektowy	wcale nie jest obiektowy, "krwa, ten kod musi* działać!"
Ruby	pasja, elegancik, ma Rails i dobry marketing	dobry marketing, "Twitter doesn't scale", każda metoda ma 5 aliasów, kaskady tysięcy end-ów
Perl	wyrażenia regularne	język tylko do zapisu, równie czytelny co wyrażenia regularne
Python	indentacje! (coś wspaniałego), elegancik, DJ Ango	prawie jak Ruby; tuple, dictionary - normalniej się tego nie dało nazwać?
C#	podobno dobre IDE (Visual Studio)	gdzie jest znak 'sharp' na klawiaturze?
JavaScript	AJAX, jQuery, mało ma wspólnego z Javą :D	alert("Prawy przycisk został zablokowany. Złodzieju.");
Assembler	kilka rozkazów na krzyż a napiszę wszystko	kilka książek z mapami portów, DMA i opisem przerwań a napiszę hello world

A jakie skojarzenia mają Riddle i Jarosław Zabiełło? :-)

Ruby on Rails vs .NET, PHP, Django

2007-10-03T11:46:32-07:00

Swojego czasu Radarek zapostował cztery przezabawne reklamówki Railsów. Dorzucam kolejne trzy. Miłej zabawy :)

Ruby on Rails vs .NET

Ruby on Rails vs PHP

Ruby on Rails vs Django

Boskie :).

Destruktory w Rubim, czyli ObjectSpace w akcji

2007-08-13T12:35:46-07:00

Ruby (podobnie jak Java) nie posiada destruktorów. Może to się wydawać dziwne, ale okazuje się, że garbage collector załatwia za nas większość przykrych czynności, a pozostałe można zrealizować poprzez odpowiednią budowę aplikacji.

A co, jeśli się uprzemy na destruktor lub po prostu metodę, która zostanie wykonana podczas niszczenia obiektu?

"Destruktory" dla egzemplarza

one = "jeden"
two = "dwa"
three  = "trzy"

ObjectSpace.define_finalizer(one, lambda {|id| puts "\"one\" (#{id}) umarł w męczarniach" })
ObjectSpace.define_finalizer(two, lambda do |id|
                                    puts "\"two\" (#{id}) umarł w męczarniach"
                                  end)

"two" (22660860) umarł w męczarniach
"one" (22660870) umarł w męczarniach

Trzeci też umarł, ale bardziej po cichu.

"Destruktory" dla klasy

Należy tutaj pamiętać, że definiujemy metodę klasy, a nie instancji.

class TestClass
    def initialize
        ObjectSpace.define_finalizer(self, self.class.method(:finish_him!).to_proc)
    end
    def TestClass.finish_him!(id)
        puts "Flawless victory (#{id})"
    end
end

test = TestClass.new

Wymuszenie garbage collectora

Moduł ObjectSpace to nic innego jak interakcja z garbage collectorem, który działa w pełni poprawnie, ale automatycznie - nigdy nie wiemy, kiedy zostanie wywołany. Możemy jednak wywołać metodę garbage_collect, by bardziej kontrolować pracę kolektora. Niestety, niszczymy wówczas wszystkie nieużywane obiekty, ale to chyba nie jest duży (o ile w ogóle) mankament.

class TestClass
    def initialize
        ObjectSpace.define_finalizer(self, self.class.method(:finish_him!).to_proc)
    end
    def TestClass.finish_him!(id)
        puts "Flawless victory (#{id})"
    end
end

def create_garbage
  TestClass.new
end

puts "Tworzę śmieci"
create_garbage
puts "Usuwam śmieci."
ObjectSpace.garbage_collect
puts "Gotowe."

Tworzę śmieci
Usuwam śmieci.
Flawless victory (22660260)
Gotowe.

Warto pamiętać, że sprzątaniu ulegną śmieci powstałe w innych blokach niż ten, w którym poprzez wymuszenie wywoływany jest kolektor.

Pozostaje tylko pytanie: po co wymuszać? Jest to uzasadnione w naprawdę niewielu przypadkach. Innymi słowy: łapy precz. To tylko ciekawostka ;).

Ups...

ObjectSpace posiada metodę _id2ref, która zwraca referencję obiektu o podanym id.

ObjectSpace._id2ref("test".object_id) # => "test"

Kiedy wywoływany jest finalizer, przekazywany jest mu id obiektu, który właśnie został zniszczony. Szukanie referencji po takim identyfikatorze nie zadziała, bo obiektu już prawdopodobnie nie ma. Warto o tym pamiętać, by uniknąć frustrujących błędów na przyszłość.