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

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.

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.

RadRails 1.0

Jarosław Zabiełło — Thu, 13 Mar 2008 03:47:00 +0100

Pogłoski o śmierci RadRails były chyba trochę przedwczesne. Firma Aptana wypuściła przedwczoraj nowy RadRails 1.0. Wewnętrznie używany jest JRuby 1.11RC2. RadRails pozwala na uruchamianie Rubiego, JRuby i … Rubiniusa. Chwalą się nawet, że mają więcej funkcji niż Netbeans 6. Aptana dodatkowo zapewnia integrację z Jaxerem, wsparcie do Adobe AIR, i jak zwykle bardzo dobry parser do HTML, CSS i debugger JavaScript. Mimo wszystko, nie wiem czy to wszystko wystarczy, bo Netbeans 6 ma znacznie bardziej inteligentny, kontekstowy analizator kodu Rubiego, podczas gdy RadRails używa znacznie mniej wyrafinowany plugin RDT (o którym poza tym chodzą od dawna pogłoski że przestał być rozwijany). W każdym razie takie współzawodnictwo i obecność dwóch tak dobrych IDE to na pewno dobra wiadomość dla wszystkich sympatyków Ruby on 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

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.

JRuby 1.0

Jarosław Zabiełło — Wed, 13 Jun 2007 11:24:00 +0200

Ukazała się finalna wersja JRuby 1.0 – implementacji języka Ruby w czystej Javie. Zespół JRuby zachęca do testowania Railsów na JRuby. Z tego co pamiętam, to wersji finalnej JRuby zapowiadano włączenie optymalizacji kodu. Zanim zatem wyjdzie w końcu Ruby 2.0, JRuby on Rails ma już teraz szansę przełamać stereotyp o słabszej wydajności Rubiego. Szczególnie może to mieć duże znaczenie dla platformy Windows, bo Ruby na systemach POSIX (Linux, BSD, Mac OS X) pracuje znacznie wydajniej.

Dla miłośników Mac OS X jest dostępny artykuł pokazujący jak skonfigurować całe środowisko Javy dla Rail. Ale do pracy z Rails, najprościej użyć Netbeans 6 który od jakiegoś czasu pozwala¹ na uruchamianie Railsów na JRuby (można wybrać sobie opcję JRuby lub klasyczny CRuby).

Zobacz też artykuł “JRuby and the Java Platform” jaki ukazał się wczoraj na stronie firmy Sun.

¹ Szkoda, że NB6 nie ma jeszcze zaimplementowanego kolorowania i podpowiadania helperów dla Haml. Jak ktoś ma siły i czas to tu jest opis jak dodać kolorowanie dla jakiegoś innego języka.

Netbeans 6 - killer IDE dla Ruby on Rails?

Jarosław Zabiełło — Fri, 16 Mar 2007 11:39:00 +0100

Jeśli chodzi o jakość podpowiadania składni i metod Rubiego, to najnowsza, szósta wersja flagowego edytora IDE – Netbeans, deklasuje RadRailsa i resztę “towarzystwa”.

To trzeba po prostu obejrzeć na filmie! Czegoś takiego nie mają żadne inne edytory dla Rubiego. Co prawda nie ma jeszcze wersji finalnej, ale można sobie ściągnąć i zainstalować najnowszą wersję rozwojową. (Aby uaktywnić obsługe Rubiego należy wejść do Tools -> Update Center i dociągnąć plugin). Netbeans może być używany do pracy z klasycznymi Railsami lub ich wersją działającą w Javie, czyli JRuby on Rails.

Ruby skutecznie toruje sobie drogę i znajduje coraz większe zainteresowanie i wsparcie w kręgach Javy. Poza Netbeansami, wsparcie dla Rubiego i Railsów posiada też potężny IntelliJ. Zobacz ich film o Ruby i o Railsach. Mimo wysiłków twórców IntelliJ, z tego co widzę Netbeans ma jednak lepiej dopracowane wsparcie Rubiego, lepsze kolorowanie kodu i lepsze podpowiedzi. Widać tu, że zatrudnienie twórców JRuby przez firmę Sun robi swoje. Poza tym Netbeans jest darmowy (open source), a IntelliJ – nie.

Sun zatrudnił programistów JRuby

Jarosław Zabiełło — Fri, 08 Sep 2006 10:33:00 +0200

W środowisku javowców Ruby jest językiem który robi trochę zamieszania (jakoś tak się składa, że Ruby bardziej przemawia do programistów Javy niż Python). Cieszy zatem, że firma Sun podjęła decyzję o wsparciu projektu JRuby zatrudniając jego czołowych developerów. Powinno to znacznie przyśpieszyć prace nad tym projektem podobnie jak stało się z IronPythonem, gdy Microsoft zatrudnił jego twórcę.

Jestem ciekaw jak długo programiści zachowają entuzjazm dla swego języka, gdy będzie można generować taki sam bytecode Javy lecz w niezrównanie prostszy sposób. :)

Przykładowy kod Javy:

public class Filter {
  public static void main(String[] args) {
    List list = new java.util.ArrayList();
    list.add("Tim"); list.add("Ike"); list.add("Tina");
    Filter filter = new Filter();
    for (String item : filter.filterLongerThan(list, 3)) { 
      System.out.println( item ); 
    }
  }
  public List filterLongerThan(List list, int length) {
    List result = new ArrayList();
    for (String item : list) {
      if (item.length() <= length) { result.add( item ); }
    }
    return result;
  }
}

A oto odpowiadający mu kod w Ruby:

list = ['Tim', 'Ike', 'Tina']
list.select {|n| n.length > 3}.each {|n| puts n}

Oczywiście to nie wszystko. Dzięki JRuby można uzyskać efekty kompletnie nieosiągalne w standardowej Javie – np. można pracować z biblioteką Swing w sposób interaktywny, z poziomu interpretera zmieniając na żywo jej obiekty.

Wkrótce ma także być gotowa wersja Railsów działająca z JRuby (Zobacz prezentację w PowerPoint). Tym samym odeszłyby wszelkie uwagi co do wydajności Railsów, bo współczesna wirtualna maszyna Javy jest tak silnie zoptymalizowna że dorównuje językowi C++. Oczywiście model wątkowy JRuby jest zgodny z wydajnym i dojrzałym modelem wątkowym Javy – po prostu z niego korzysta.

JRuby on Rails - ruszył

Jarosław Zabiełło — Sun, 14 May 2006 20:21:00 +0200

JRuby – projekt będący implementacją Rubiego w języku Java został przyśpieszony w związku z konferencją JavaOne. Developerom udało się w końcu uruchomić pełną aplikację Railsów działającą na wirtualnej maszynie Javy. Na razie jeszcze nie ma informacji o jakimś znaczącym przyśpieszeniu działania, ale pierwszy krok został dokonany. Zobacz więcej…

Zobacz też listę języków potrafiących pracować w javowskiej JVM – jest ich całkiem sporo. Kto by pomyślał, że nawet napisano assembler generujący klasy Javy. :)