Jarosław Zabiełło - BLOG :

Rails 3.0 beta

Wed, 24 Feb 2010 03:30:00 +0100

Muszę przyznać, że wydana parę tygodni temu wersja beta Ruby on Rails 3.0 wygląda bardzo obiecująco. Choć to dopiero beta, to wprowadzone razem z nią ulepszone zarządzanie gemami za pomocą Bundler'a robi dobre wrażenie. Aby ułatwić sobie eksperymentowanie z nowym RoR 3.0, najlepiej zainstalować wpierw RVM...

RVM (Ruby Version Manager)

RVM (http://rvm.beginrescueend.com/) wprowadza nową jakość do niezbyt wygodnego zarządzania wersjami Ruby’ego jakie było do tej pory stosowane. Pozwala na instalację, izolację i błyskawiczne przełączanie się między różnymi wersjami (i implementacjami!) Ruby’ego – od stabilnych po rozwojowe, od Ruby 1.8.0 po 1.9.2 preview1, JRuby, IronRuby, MacRuby (dla OS-X), MagLev czy Rubinius.

rvm list known – wyświetli listę wszystkich dostępnych instalacji
rvm install 1.9.1 – zainstaluje Ruby 1.9.1
rmv use 1.9.1 --default – ustawi Ruby 1.9.1 jako domyślną wersję (dla nowej konsoli)
rvm use system – powróci do ustawień systemowych
rvm help – wyświetli dostępne komendy

     
$ rvm install 1.9.1              
$ rvm use 1.9.1
$ which ruby
/Users/adm/.rvm/rubies/ruby-1.9.1-p378/bin/ruby 
$ which gem
/Users/adm/.rvm/rubies/ruby-1.9.1-p378/bin/gem

Instalacja i przełączenie się na najnowszego JRuby’ego:

$ rvm install jruby-head
$ rvm use jruby-head

$ which ruby
/Users/adm/.rvm/rubies/jruby-head/bin/ruby

$ which gem
/Users/adm/.rvm/rubies/jruby-head/bin/gem

$ ruby -v
jruby 1.5.0.dev (ruby 1.8.7 patchlevel 174) (2010-02-23 944db04) (Java HotSpot(TM) 64-Bit Server VM 1.6.0_17) [x86_64-java]

Powrót do Ruby 1.9.1:

       
$ rvm use 1.9.1
$ ruby -v
ruby 1.9.1p378 (2010-01-10 revision 26273) [i386-darwin10.2.0]

Proste i wygodne. Nigdy więcej paskudnych nazw typu ruby1.8, ruby1.9, gem1.9 itp. Koniec też z niespójnością skryptów które mają taką samą nazwę ale różną linijkę shebang (wskazującą jaki interpreter Ruby’ego należy użyć dla odpalenie skryptu).

Zobacz też screencast Rails 3 Beta and RVM.

Uwaga: w wypadku używania RVM nie należy używać komendy sudo (dla systemów POSIX) gdyż wszystkie wersje Ruby’ego wraz ze swymi gemami są instalowane w katalogu domowym użytkownika ~/.rvm.

Updated 2010-02-28:

W wypadku korzystania z wersji rozwojowych, np. jruby-head lub maglev-head, aktualizacja do najnowszej wersji polega na usunięciu i zainstalowaniu danego interpretera Ruby’ego. Ta operacja jednak nie wymaga reinstalacji gemów bo nie są one kasowane.

       
rvm remove maglev-head
rvm install maglev-head

Rails 3 i bundler

Instalacja bety Rails 3.0 jest prosta. Zakładając że mamy wiele wersji Ruby’ego, i wiedząc że Rails 3 wymaga Ruby w wersji minimum 1.8.7, cała instalacja sprowadza się do krótkiego polecenia:

gem install rails --pre

Z tego co sprawdziłem, nie ma już potrzeby instalowania całej listy wcześniejszych gemów, jak to podawano na oficjalnym blogu Rails.

Razem z instalacja Rails 3 beta zostanie zainstalowany gem bundler. Od tego momentu, można używać skryptu bundle zamiast gem. W Rails 3 zależności między gemami dla aplikacji są ustawianie w pliku Gemfile. To jest główne miejsce gdzie są ustawiane wszystkie zależności. Jeśli nasza aplikacja potrzebuje do swej pracy jakiegoś konkretnego gemu, to tam należy to sobie dodać. Wybrane komendy:

bundle check – sprawdzi czy nie brakuje nam jakiegoś gemu niezbędnego do działania aplikacji RoR3

bundle install – instaluje wszystkie gemy niezbędne do działania aplikacji RoR3

bundle lock – “zamraża” gemy potrzebne dla aplikacji RoR3 tworząc plik Gemfile.lock. Nie jest możliwe instalowanie gemów (wcześniejsze )

bundle pack – kopiuje gemy potrzebne do aplikacji do vendor/cache

bundle show – wyświetli listę gemów używanych przez aplikację RoR3

bundle install --relock – instaluje najnowsze (jeśli trzeba) wersje gemów i ponownie zamraża listę gemów.

Wczesniejsze komendy rake rails:freeze:gems czy rake rails:unfreeze nie są zalecane. Zamiast nich należy używać bundler’a.

Zobacz też screencast Bundler.

Rails 3 – zmiany

Poza większą wydajnością i modularnością, w Rails 3 wprowadzono szereg innych zmian i ulepszeń. M.in. zlikwidowano grupę skryptów z katalogu script/ i zastąpiono go jednym – rails. ActiveRecord, dzięki nowemu gemowi http://github.com/nkallen/arel uzyskał bardziej obiektową składnię oraz opóźnione (lazy) wywoływanie połączeń z bazą. Dane są pobierane z bazy dopiero w momencie kiedy są potrzebne. To ułatwia ich buforowanie, składanie z warunków oraz testowanie. Nowy AR doczekał się, wzorowanego na Sequelu, polecenia .to_sql dzięki któremu można wyświetlić generowany kod SQL przed jakimkolwiek połączeniem z bazą. Zobacz też screencast Active Record Queries in Rails 3.

Rails 3 wspiera również tzw. nieiwazyjny JavaScript (czyni to za pomocą składni z HTML5) dzięki czemu helpery widoku nie generują już więcej wstawek JavaScriptu w kodzie HTML. Łatwiej zatem przełączyć się z (domyślnego) Prototype na inną bibliotekę, np. jQuery.

Wspomniana wcześniej modularność Rals 3 to też silna strona nowej wersji tego frameworka. Każdy wcześniejszy główny moduł składający sie na Rails został gruntownie przebudowany i odizolowany. Rails 3 nie posiada znanych z wersji 2.x zależności frameworka od Active Record. Zarówno Active Record jaki i Action Controller czy Action Mailer są niezależnymi modułami które można sobie wyłączyć lub wymienić (np. teraz jest łatwiej wymienić Active Record na inny ORM). Z perspektywy Rails 3 wszystkie te moduły są nowymi pluginami (zobacz Railtie). Rails 3 wprowadził także montowalne aplikacje. Każda aplikacja Rails 3 może być użyta jako komponent wchodzący w część kolejnej aplikacji Rails 3. W zasadzie to nie dotyczy tylko Rails 3 ale dowolnego frameworka zgodnego z webowym interfejsem Rack. Tzn. w Rails 3 można wpiąć sobie w wybrane adresy URL zarówno inna aplikację Rails 3 jak i Sinatrę, Merba, Ramaze czy inny framework zgodny z Rack (teraz praktycznie wszystkie są z tym zgodne).

Dokładniejsza lista zmian jest dostępna na

Rails 3.0: Release Notes

Zobacz też artykuły Yehuda Katz’a na blogu oraz na stronach firmy Engine Yard:

Scala i bezpieczny "duck typing"

Sat, 23 Jan 2010 07:40:00 +0100

Duck typing (opisywany przeze mnie wcześniej na przykładzie Pythona) to dosyć użyteczna technika popularna w językach dynamicznie typowanych. W typowym języku statycznie typowanym, takim jak Java, nie da się jej stosować. Ale ograniczeniem nie jest statyczne typowanie, lecz to że Java, jako język, jest po prostu słaba. W statycznie typowanej Scali “duck typing” to żaden problem. Mało tego. Fakt, że Scala jest statycznie typowana daje jej tu dodatkową przewagę na językami dynamicznie typowanymi.

Duck typing w języku dynamicznie typowanym ma pewne wady od których Scala jest wolna. Wpierw przykład dla języka Ruby:

class Kaczka
  def kwacz
    puts "kwa kwa" 
   end
end   

class Slowik
  def kwacz
    puts "fiu fiu" 
  end
end

class Kot
  def miau
    puts "miau miau" 
  end
end

def kwacz_kaczuszko(k)        
  k.kwacz
end

kwacz_kaczuszko(Kaczka.new) # => kwa kwa
kwacz_kaczuszko(Slowik.new) # => fiu fiu
kwacz_kaczuszko(Kot.new) 
# => NoMethodError: undefined method ‘kwacz’ for #<Kot:0x000001010195d8>

Błędy tego typu są trudne do wyłapania w językach dynamicznie typowanych, bo o ich wystąpieniu można się dowiedzieć dopiero w trakcie działania programu. I jeśli taki fragment kodu jest wykonywany rzadko, to trudno powiedzieć kiedy zostanie wychwycony. Jedynym sposobem aby tak błąd odpowiednio wcześniej wyłapać jest pisanie dodatkowych testów jednostkowych.

Co prawda, powyższy kod można co prawda lekko zmodyfikować (bo Ruby pozwala na ładne odpytanie obiektu, czy jest w stanie wywołać daną metodę)

def kwacz_kaczuszko(k)        
  if k.respond_to? :kwacz      
    k.kwacz                
  else
    puts "ja nie kwaczę!" 
  end
end

kwacz_kaczuszko(Kot.new) # => ja nie kwaczę!

Tylko czy to coś zmienia? Zamiast pisać dodatkową obsługę takiego błędu, nie lepiej go po prostu nie mieć?

Scala takie błędy wyłapuje już na etapie kompilacji. Tym samym gwarantuje (statycznie) że do kodu nic takiego się nie prześliznie. Można powiedzieć, że Scala obsługuje “duck typing” w sposób bezpieczny, prawidłowy. Odpada pisanie testów jednostkowych i obsługiwanie takich błędów bo w Scali one nigdy się nie pojawią!

class Kaczka {
  def kwacz {
    println("kwa kwa")
   }
}

class Slowik {
  def kwacz {
    println("fiu fiu")
   }  
}

class Kot {
  def miaucz {
    println("miau miau")
  }
}                     

def kwacz_kaczuszko(k : {def kwacz}) {
  k.kwacz
}

kwacz_kaczuszko(new Kaczka) 
kwacz_kaczuszko(new Slowik)
kwacz_kaczuszko(new Kot)

/*
(fragment of przyklad.scala):25: error: type mismatch;
 found   : this.Kot
 required: AnyRef{def kwacz: Unit}
kwacz_kaczuszko(new Kot)
                 ^
one error found

!!!
*/

Uwolnienie potęgi iPhona - jailbreaking

Sun, 17 Jan 2010 03:58:00 +0100

Tak, jak pewnie większość użytkowników iPhone’a, mimo że słyszałem od dawna o możliwości zdjęcia apple’owskich blokad (proces określany jako jailbreaking), to trochę się obawiałem że taka operacja to potencjalne ryzyko zablokowania aparatu lub jakichś innych nieodwracalnych uszkodzeń. Prawda jest taka, że to wszystko to brednie i ploty. Jailbreak jest bardzo łatwy do przeprowadzenia i jest to proces w pełni odwracalny.

Jailbreak iPhone’a wytrąca z ręki krytyków tego urządzenia większość argumentów. Nie wszyscy wiedzą, ale Cydia (jedno z najpopularniejszych zasobów aplikacji na jailbreakowanego iPhone’a) istniała na długo zanim Apple wpadł na pomysł ze swoim AppStore. Aktualnie istnieje już wiele tego typów repozytoriów aplikacji, wszystkie są integrowane w jeden, szybki system za pomocą pakietu Rock (o czym niżej).

Czy są jakieś wady (lub ograniczenia) związane z jailbreakiem? Owszem, jest pewna niedogodność. Przed aktualizacją kolejnej wersji systemu operacyjnego iPhone\a (co jest dosyć rzadkim wydarzeniem) należy przywrócić z powrotem oryginalny system, zrobić aktualizację, i dopiero po tym odpalić ponownie jailbreak (choć przy większych zmianach iPhone OS można się wcześniej upewnić czy jailbreak już jest z nim kompatybilny).

Dla pewności, dobrze zrobić sobie backup iPhone (oczywiście za pomocą ITunes). Gdyby cokolwiek poszło źle można łatwo odzyskać z powrotem poprzednią zawartość iPhone’a.

Jailbreak (przy okazji usuwany jest simlock) przeprowadza się w banalny sposób. Należy podpiąć iPhone kabelkiem USB do komputera i uruchomić program blackra1n ściągnięty ze strony http://www.blackra1n.com (program jest dostępny zarówno dla Mac OS-X jak i dla sytemu Windows)

Po kliknięciu w przycisk “make it ra1n”, może pojawić się okienko ITunes z informacją że iPhone został przełączony w tryb recovery. Można je spokojnie zignorować.

Po odpaleniu blackra1n iPhone zostanie przeładowany, a na liście aplikacji pojawi się dodatkowa blackra1n. Należy ją uruchomić. Z zaproponowanych do instalacji pakietów: Cydia, Rock i sn0w. Należy wybrać Rock (zobacz: http://www.rockyourphone.com). Jest dużo szybszy od Cydii i oczywiście wszystkie aplikacje dostępne dla Cydii są też dostępne dla Rock’a. Poza tym Rock posiada automatyczny system backupu. Wystarczy zarejestrować sobie darmowe konto na serwerze (robi się to z poziomu Rock’a) i wtedy nie trzeba się przejmować aby robić backup ściągniętych aplikacji. Rock zrobi to automatycznie i automatycznie je przywróci jak trzeba. Do kontrolowania pakietów/aplikacji Rock używa APT, system podobny do używanego w Debianie/Ubuntu, lecz wszystko działa w ładnym GUI.

Jeśli po jailbreake’u masz jakieś problemy z działaniem Wifi, należy zrestartować w iPhonie ustawienia sieciowe (Ustawienia -> Ogólne -> Wyzeruj -> Wyzeruj ustawienia sieciowe) Ja musiałem to zrobić dwa razy. Od tego momentu już więcej nie było problemów.

Co warto sobie zainstalować na początek?

Na pewno warto zacząć od SBSettings (oczywiście wszystko się instaluje za pomocą aplikacji Rock). SBSettings to b. wygodna aplikacja, pozwala ubijać inne aplikacje, wyświetla ilość dostępnego RAM’u, pozwala czyścić RAM, chować ikony innych aplikacji itp.

Drugą aplikacją “must have” to Backgrounder – służy do odpalania dowolnej innej aplikacji w tle.

Trzecią to Categories pozwalająca na grupowanie ikon programów w foldery. Dużo wygodniej niż stary bałagan, zwłaszcza jak się ma dużo aplikacji.

Do łatwiejszej lokalizacji aplikacji (bo są w katalogach o mało czytelnych nazwach) dobrze doinstalować sobie Prostą aplikację AppLinks (w /var/mobile/AppLinks stworzy czytelne linki symboliczne do wszystkich aplikacji).

Co dalej? No, zależy co kto potrzebuje. Ja zainstalowałem sobie Pythona, Ruby, Haskella, Javę (kompaktowa JamVM), Scalę, Clojure, Vim’a, Midnight Commandera, wget, lynx, git, svn oraz oczywiście serwer OpenSSH. Dzięki temu ostatniemu mogę połączyć się z iPhonem za pomocą SSH (dla tych co nie wiedzą, domyślne hasło root’a w iPhonie to “alpine”). Dzięki SSH można łatwo modyfikować dowolne pliki i aplikacje. Przeszkadzają komuś reklamy w jakimś programie? :) Najczęściej wystarczy tylko prosta edycja pliku javascriptowego. Poza tym za pomocą SFTP można przerzucać dowolne programy i pliki z pominięciem iTunes. Jest nawet program Installous specjalnie do instalowania aplikacji bez pośrednictwa ITunes.

$ ruby -v
ruby 1.8.6 (2007-09-24 patchlevel 111) [arm-darwin9]

$ python    
Python 2.5.1 (r251:54863, xx/xx/xx, xx:xx:xx) 
[GCC 4.2.1 (Based on Apple Inc. build 5555)] on darwin

$ java -version
java version "1.5.0" 
JamVM version 1.5.1
Copyright (C) 2003-2008 Robert Lougher <rob@lougher.org.uk>
...
Execution Engine: direct-threaded interpreter with stack-caching
Compiled with: gcc 4.2.1 (Based on Apple Inc. build 5555)

Boot Library Path: /usr/lib/classpath
Boot Class Path: /usr/share/jamvm/classes.zip:/usr/share/classpath/glibj.zip

Python zainstalował mi się w wersji 2.5. Za pomocą setuptools doinstalowałem ipythona, django, pylons, sqlalchemy, mako. Odpaliłem prosty projekt w Django. Działa bez problemu. Ruby instaluje się w wersji 1.8.6 ale ma starsze RubyGems 1.3.2. Ściągnąłem zatem z sieci najnowsze i bez problemu doinstalowały się: Rails, Merb i Sinatra. Niestety jako serwer działa tylko Webrick. Thin i Mongrel się nie skompilowały, ale to dlatego że nie miałem programu make.

Powodzenia w hackowaniu. Teraz to iPhone naprawdę Rocks ;)

Spotkanie entuzjastów Scali z okolic Wrocławia

Fri, 15 Jan 2010 02:37:00 +0100

W najbliższy wtorek (19 stycznia 2010) odbędzie się pierwsze spotkanie WrASSE (grupy entuzjastów Scali z okolic Wrocławia) pt. “Scala w projekcie komercyjnym”. Szczegóły: tutaj.

IPLA i odbieranie live TV spoza Polski

Sat, 12 Dec 2009 14:58:00 +0100

Osoby mieszkające poza Polską, nawet jeśli mają wykupiony abonament na odbiór strumieniowych kanałów telewizji Polsat, mogą poczuć się oszukani, że transmisje na żywo z co ciekawszych wydarzeń są dla nich niedostępne. Poniżej podaję prosty sposób jak to obejść i ośmieszyć takie “polsatowe” blokady. Sposób jest jak najbardziej legalny i nie wymaga nigdzie żadnego włamywania się, ani hackowania programu IPLA.

Należy ściągnąć program IPLA ze strony http://ipla.pl. Ale uwaga, musi to być wersja dla systemu Windows bo wersja Lite dostępna dla Mac OS-X lub Linuksa się nie nadaje. Nie ma opcji logowania niezbędnej do użycia konta VIP bez którego nie można korzystać z transmisji na żywo. Użytkownicy Mac OS-X (lub Linuksa) mogą skorzystać z dowolnego emulatora Windowsów, np. VMWare, Parallers lub darmowego VirtualBoxa. Dla OS-X używam najlepszego moim zdaniem, VMWare Fusion. (Nie sprawdzałem czy można odpalić IPLĘ przez Wine lub CrossOver, czyli programy pozwalające uruchamiać aplikacje windowsowe bez zainstalowanego systemu Windows. Jeśli tak, to odpada posiadanie samych Windowsów). Zakładam dalej, że używamy do tego celu Windows (bezpośrednio, lub spod emulatora).

Transmisje na żywo są dostępne tylko dla użytkowników posiadających konto VIP. Trzeba się zarejestrować i wykupić jakiś abonament. Najtańszy, 30-dniowy kosztuje 14 zł.

Potrzebne będzie jakieś konto shellowe na polskim serwerze oraz program do obługi SSH, np. Putty SSH. Ważne aby takie serwer stał w Polsce a nie za granicą.

Aby sobie ułatwić ustawianie proxy, najwygodniej pobrać program Proxifier.

1. Zestawiamy tunelowanie SSH do polskiego serwera. Można to sobie ustawić w Putty SSH albo uruchomić w konsoli komendę:

putty.ssh  -D 127.0.0.1:1044 login@jakis.server.pl

Po podaniu hasła i zalogowaniu, mamy zestawiony tunel między lokalnym komputerem na porcie 1044 z zdalnym “jakis.server.pl”.

2. Należy odpalić Proxyfier, wejśc do menu -> Options -> Proxy Settings i ustawić

address: 127.0.0.1
port 1044
socks: 5

3. Odpalamy program IPA i logujemy się do swojego konta VIP

To wszystko. Dla Polsatu będziemy widziani jako użytkownik łączący się z Polski. Można oglądać wszelkie transmisje Live.

MagLev - pierwsza wersja publiczna

Sat, 21 Nov 2009 04:43:00 +0100

Gdy ok 1.5 roku pisałem o szumie i nadziejach związanych z MagLev’em, trudno było przewidzieć ile czasu zajmie dostosowanie wirtualnej maszyny Smalltalka do pracy z kodem bajtowym Ruby’ego. Dziś (właściwie to jakieś 2 godziny temu) oficjalnie ogłoszono że jest dostępna publicznie pierwsza wersja alpha. Z tego, co podaje dokumentacja, to Maglev jeszcze nie działa tam gdzie są wymagane rozszerzenia w C, ale w przykładach widać, że działa Sinatra, Rack, RubyGems czy interaktywna konsola. Najciekawsza jest transakcyjna, przezroczysta pamięć stała MagLev’a, bo to zupełnie zmienia styl myślenia i pracy z danymi. Może będzie można w końcu zapomnieć o przestarzałych ORM’ach i RDBMS? (technologia baz relacyjnych pochodzi z lat 70-tych, jest wolna i przestarzała).

Ruby everywhere – czyli najważniejsze implementacje Ruby’ego:

Ruby 1.8 MRI – implementacja w języku C (najstarsza)
Ruby Enterprise Edition – implementacja w C, mniejsze zużycie pamięci, używana głównie z Passengerem
Ruby 1.9 – implementacja w języku C, używa wirtualnej maszyny YARV
JRuby – implementacja w języku Java, wirtualna maszyna Javy (JVM)
IronRuby – implementacja w języku C# (środowisko .NET)
Maglev – implementacja w języku Smalltalk, wirtualna maszyna Smalltalka (Gemstone)
MacRuby – implementacja w języku Objective-C dla systemu Mac OS-X
Rubinius – implementacja Ruby w… Ruby (z loaderem w C++)
BlueRuby – Ruby działający w SAP Web Application Server (ABAP Virtual Machine)

Zobacz też State of Ruby VMs: Ruby Renaissance

Scala w Trójmieście

Mon, 09 Nov 2009 21:29:00 +0100

19 listopada 2009 w auli Uniwersytetu Gdańskiego odbędzie się spotkanie poświęcone językowi Scala. Organizuje je Trójmiasto Java User Group. Szczegóły tutaj: http://it.wtrojmiescie.org/spotkania/scala.

RubyMine - najlepszy IDE dla Ruby i Rails

Tue, 13 Oct 2009 00:13:00 +0200

Mimo, że spora część programistów Ruby’ego i Rails pozostaje wierna edytorom tekstowym takim jak TextMate, Emacs, Vim czy (opisywany dwa lata temu) JEdit, druga część woli IDE ze względu na rozbudowany lepszy refactoring, wbudowany (graficzny) debugger, podpowiedzi i analiza składni kodu Ruby’ego w czasie rzeczywistym. Z różnych IDE do Rails to tak naprawdę liczą się tylko trzy.

Jednym z pierwszych IDE do Rails był (oparty na Eclipse) RadRails, który później został wchłonięty przez Aptanę i jest rozprowadzany jako Aptana RadRails.

Znacznie lepszą od Aptany analizę kodu Ruby’ego w czasie rzeczywistym posiada Netbeans który, będąc produktem darmowym i obsługującym wiele języków (Ruby, Python, PHP, Scala, Java itp) do dziś ma wielu zwolenników.

Od jakiegoś czasu mam przyjemność pracować z produktem RubyMine i muszę przyznać, że jest jeszcze lepszy od Netbeans (którego rozwój jakby ostatnio coś zwolnił). Aktualnie wyszła wersja 2.0beta która ma sporo dodanych ulepszeń, wspiera podpowiedzi do Cucumber, RSpec, Haml, i18n czy Ruby 1.9. Działa faktycznie szybko i przyjemnie (zobacz np. jak elegancko rozwiązano nawigację po kodzie). Mimo, że RubyMine to aplikacja płatna, to zdecydowanie jest warta swej ceny (przed wyjściem wersji finalnej 2.0 dostępna jest zniżka 20%)

Jeśli ktoś chce używać nie tylko Ruby, ale także Scali i innych języków, dostępny jest potężny IntelliJ IDEA (RubyMine jest tam dostępny w formie pluginu).

Rails dopalony Sinatrą

Tue, 13 Oct 2009 00:11:00 +0200

Dostępne w Rails 2.x kontrolery rackowe (tzw. metal applications) wprowadzono aby maksymalnie przyśpieszyć działanie Rails (pomijają prawie cały stos wywołań frameworka). Ich wadą jest trochę niewygodna, niskopoziomowa składnia. Z drugiej strony, dzięki Rackowi, istnieje kilka bardzo szybkich mikroframeworków, z których najbardziej znany to Sinatra i Ramaze. Dzięki możliwości wpięcia ich do Rails, uzyskuje się połączenie dużej szybkości z wygodniejszą składnią.

Klasyczny kontroler rackowy, stworzony za pomocą generatora kodu

  
$ script/generate metal hello

wygląda tak:

  
require(File.dirname(__FILE__) + "/../../config/environment") unless defined?(Rails)
class Hello
  def self.call(env)
    if env["PATH_INFO"] =~ /^\/hello/
      [200, {"Content-Type" => "text/html"}, ["Hello World!"]]
    else
      [404, {"Content-Type" => "text/html"}, ["Not Found"]]
    end
  end
end

Po zastąpieniu go Sinatrą, kod staje się bardziej znośny:

  
require 'sinatra/base'
class Hello < Sinatra::Base
  get '/hello' do
    "Hello World!" 
  end
end

Wydajnościowo (na MacBook Pro 2.16GHz Core2 Duo, Ruby 1.9.1 i Thin 1.2.4 i dla ab -n 10000 -c 10) różnice wyglądają następująco:

czysty metal: 2054 req/s
metal z Sinatrą: 1335 req/s
klasyczny kongtroler: 456 req/s

Co prawda, wciąż czysty kontroler rackowy jest najszybszy, ale zastąpienie go Sinatrą i tak jest dużo szybsze od normalnego kontrolera Rails. Poza tym uzyskujemy uproszczenie kodu (może na podanym, trywialnym przykładzie nie jest to spektakularne, ale przy bardziej złożonym zalety takiego rozwiązania stają się bardziej oczywiste)

Aplikacja multiplatformowa za pomocą cross-kompilatora

Thu, 10 Sep 2009 02:00:00 +0200

Od jakiegoś czasu interesuje mnie możliwość pisania aplikacji działających na różnych systemach operacyjnych. Rozwiązaniem najbardziej oczywistym jest oczywiście użycie Javy (może niekoniecznie samego języka jako takiego, ale na pewno platformy). Rozwiązaniem znacznie mniej znanym, ale ciekawym, jest użycie produktu firmy Real Software – RealBasic’a.

RealBasic to prosty język obiektowy (podobny do Visual Basica). RealBasic to jednak nie tylko język, to także ciekawe zintegowane środowisko programistyczne (IDE). Jest ciekawe, bo posiada wbudowany cross-kompilator – z jednej aplikacji można automatycznie wygenerować kod binarny dla trzech głównych platform: Mac OS-X, Linux i Windows. W przeciwieństwie do Javy nie ma tu żadnej wirtualnej maszyny. Kod wynikowy jest kodem binarnym dla danej platformy. Jedno kliknięcie i trzy wersje programu gotowe. Oczywiście IDE można uruchomić także na każdej z trzech w/w platform. Twórcy RealBasica podkreślają pewną przewagę takiego rozwiązania nad Javą.

Sam edytor jest ładny i intuicyjny w obsłudze (przypomina trochę Delphi). Dokumentacja jest dobra i przejrzysta. Standardowo obsługiwane są bazy danych takie jak PostgreSQL, MySQL a także oparty na SQLite – RealServer. Wszystkie bazy korzystają z identycznego API, więc można je łatwo zmienić bez większych zmian w kodzie źródłowym aplikacji.

Niestety, nie jest to rozwiązanie open-source, ale płatne (z wyjątkiem wersji Personal Edition for Linux która jest darmowa do projektów open-source). Lecz mimo to, jeśli ktoś chce prosto i szybko zmontować aplikację która natywnie będzie pracować pod kilkoma głównymi platformami, to może to być kusząca perspektywa. Tym bardziej, że całość jest po prostu łatwa w obsłudze.

Problem znaków UTF-8 w Scali i Javie pod Mac OS-X

Tue, 08 Sep 2009 03:15:00 +0200

Wczoraj, na polskim kanale IRC #scala.pl mieliśmy małą dyskusję na temat złego wyświetlania polskich znaków w Scali pod systemem Mac OS-X Leopard (pod Linuksem jest OK). Co dziwne, mimo, że zmienna środowiska LANG pokazuje wartość pl_PL.UTF-8, próby wyświetlenia polskich napisów nie działają. Więcej, w konsoli Scali w ogóle nie ma możliwości wprowadzenia polskich znaków, ani bezpośrednio z klawiatury, ani poprzez wklejenie ze schowka. Wszystkie polskie ogonki zamieniane są na znak zapytania.

     
println(java.nio.charset.Charset.defaultCharset) 
// x-MacCentralEurope

println("Zażółć gęślą jaźń")
// Za???? g??l? ja??

Jak podaje Mac Dev Center domyślnym kodowaniem znaków w Javie pod systemem Mac OS-X jest… MacRoman. (Tak jest oczywiśie tylko w wypadku angielskiego interfejsu. Po przełączeniu na polski, domyślnym kodowaniem znaków pod Javą staje się x-MacCentralEurope).

Najgorsze, że nie pomaga, pozornie oczywiste, użycie javowego API zmieniające własność file.encoding.

     
System.setProperty("file.encoding", "UTF8")
println(java.nio.charset.Charset.defaultCharset) 
// x-MacCentralEurope

Dla sprawdzenie, czy problem ten dotyczy tylko Scali, skompilowałem testowy kod Scali do Javy i uruchomiłem go z jej poziomu.

     
// plik Znaki.scala
object Znaki extends Application {
  println(java.nio.charset.Charset.defaultCharset) 
  println("Zażółć gęślą jaźń")
  System.setProperty("file.encoding", "UTF8")
  println(java.nio.charset.Charset.defaultCharset) 
  val s = "Zażółć gęślą jaźń" 
  println(new String (s.getBytes(), "UTF-8"))    
}

$ scalac Znaki.scala
$ java -cp $SCALA_HOME/lib/scala-library.jar:. Znaki

x-MacCentralEurope
Za???? g??l? ja??
x-MacCentralEurope
Za? g??l? ja??

Po obejrzeniu pliku java/nio/charset/Charset.java wydawałby się że można problem rozwiązać za pomocą refleksji.

                                              
// plik java/nio/charset/Charset.java

private static volatile Charset defaultCharset;

public static Charset defaultCharset() {
    if (defaultCharset == null) {
        synchronized (Charset.class) {
            java.security.PrivilegedAction pa =
                new GetPropertyAction("file.encoding");
            String csn = (String)AccessController.doPrivileged(pa);
            Charset cs = lookup(csn);
            if (cs != null)
                defaultCharset = cs;
            else 
                defaultCharset = forName("UTF-8");
        }
    }
    return defaultCharset;
}

Niestety, mimo że za pomocą refleksji można zmienić wartość defaultCharset, nadal to nie rozwiązuje poprawnego wyświetlania polskich znaków.

import java.nio.charset._

println(Charset.defaultCharset) 
// x-MacCentralEurope 

val f = classOf[Charset].getDeclaredField("defaultCharset")
f.setAccessible(true)
// f.set(null, null)
// System.setProperty( "file.encoding", "utf-8")
// lub krócej:
f.set(null, Charset.forName("utf-8"))

println(Charset.defaultCharset) 
// UTF-8

println("Zażółć gęślą jaźń")
// Za???? g??l? ja??

Okazuje się, że jedynym, skutecznym i zarazem prostym rozwiązaniem tego problemu jest dodanie flagi -Dfile-encoding=utf8 do wywolania kodu Javy.

$ java -Dfile.encoding=utf8 -cp $SCALA_HOME/lib/scala-library.jar:. Znaki
UTF-8
Zażółć gęślą jaźń
UTF-8
Zażółć gęślą jaźń

W wypadku Scali, powyższą flagę dodajemy do skryptu shellowego scala. Przy okazji naprawi się wpisywanie i wyświetlanie polskich znaków w interaktywnej konsoli Scali.

Oczywiście powyższy problem ze znakami UTF-8 ostatecznie nie ma ze Scalą nic wspólnego. To wina takiego, a nie innego, zachowania się Javy w Mac OS-X. Scala “z rozpędu” ten problem tylko “odziedziczyła”, gdyż działa na bazie JVM.

Czy Apple jest droższy od PC?

Sat, 15 Aug 2009 01:52:00 +0200

Czy spotkałeś się z obiegową opinią że komputery Apple’a są dużo droższe od analogicznych odpowiedników z segmentu PC? Jeśli tak, to przeczytaj i pokaż ten tekst tym co takie brednie rozpowszechniają. Napisałem go, aby odsyłać do niego niedowiarków, bo już znudziło mi się prostowanie bzdur wypisywanych na ten temat.

W zasadzie nie jest łatwo znaleźć odpowiednik PC dla takiego laptopa MacBook Pro. Ale aby porównanie cen miało jakikolwiek sens, postawiłem zestawić maksymalnie podobny sprzętowo laptop w ramach tego samego kraju. Ze strony Appl’e wybrałem laptopa MacBook Pro i desktopowego MacPro…

MacBook Pro (http://apple.ie) vs DELL Precision M4440 (http://dell.ie)

Procesor: Core2Duo 2.66GHz, 6MB L2 Cache, 1066MHz
Pamięć: 4GB 800Hz DDR2 (niestety, nie było opcji wybrania pamięci DDR3 1066, co jest dziwne, gdyż ten procesor pracuje z 1066MHz, idealnie dla takich pamięci)
OS: English Windows Vista Ultimate SP1
Monitor 15.4” antiglare 1440×900
Grafika: nVidia FX1700M, 512MB
HD: 500GB SATA, 5400rpm
8x DVD+-/RW
Podświetlana klawiatura
Bateria 9 cell 85W W/HR LI-ION
Wifi Intel Pro Wireless 5300 (802.11a/g/ Draft-n 3×3) MiniCard for Centrino 2 Label
Bluetooth: EMEA Dell Wireless 370 Bluetooth 2.1 MiniCard
Kamerka 0.3 Mega Pixel + mikrofon
USB/Firewire: brak informacji odnośnie portów USB (ale pewnie jakieś ma) oraz Fireware (tu domyślam się że nie ma, bo by się pochwalili, a jak ma to na pewno nie szybki FW800)
Karta sieciowa: brak informacji, nie wiem czy ma i jaką, załóżmy że jakąś ma.
SD-card: brak informacji, pewnie nie ma

CENA KOŃCOWA (z VAT i dostawą): 3019 euro

MacBook Pro 15-inch
Procesor: taki sam jak w DELL’u
Pamięć: też 4GB ale szybsza od tej w DELL’u, bo DDR3 1066MHz
OS: Mac OS-X Leopard 10.5 64bit
Monitor: też 15.4” i też natywna rozdzielczość 1440×900, też matowy (domyślnie proponowany jest glossy)
Grafika: dwie karty graficzne: nVidia GeForce 9600M GT (512MB własnej pamięci) oraz nVidia 8400M z pamięcią współdzieloną z RAM
HD: taki sam
DVD: SuperDrive, mniej więcej podobny
też podświetlana klawiatura
Bateria litowo-polimerowa o wydłużonym czasie pracy – do 7 godzin z włączonym WiFi!
Wifi: Built-in AirPort Extreme Wi-Fi wireless networking2 (based on IEEE 802.11n draft specification); IEEE 802.11a/b/g compatible
Bluetooth: wbudowany Bluetooth 2.1 + EDR (Enhanced Data Rate) – to chyba jakaś przyśpieszona wersja
Kamerka: iSight – wbudowana + mikrofon
2 x USB2 + 1 x Firewire 800
SD card
MagSave – kabel zasilający wpinany jest na magnes. Potknięcie się o kabel nie grozi zrzuceniem laptopa ze stołu. Oczywiście, DELL tego nie ma.

CENA KOŃCOWA (z VAT i dostawą): 2032 euro

Jak widać, laptop firmy Apple jest DUŻO tańszy od DELL’a – aż o prawie 1000 euro!

Zasadniczo oba modele są porównywalne, choć MBP jest lepiej wyposażony. Ma FW800 oraz przydatny MagSave oraz co ważniejsze, specjalną baterię o bardzo długim czasie pracy. System operacyjny Apple’a też od razu oferuje wszystkie wersje językowe. Windowsy zaś są sprzedawane oddzielnie dla każdej wersji językowej, co powoduje dodatkowe koszty. Apple też ma dużo lepszy (bo multitouch) trackpad. Ma też pilota, ale już go nie włączałem do zestawu. MBP ma też 2 karty graficzne dzięki czemu może jeszcze bardziej oszczędzać baterię. Karty są mniej więcej podobne, choć ponoć te w DELL’u są lepiej zoptymalizowane do oprogramowania CAD, ale już niekoniecznie do gier. Można próbować trochę zbić cenę DELL’a wstawiając słabszą nVidia FX770M ale to raptem oszczędność tylko 230 euro, co sprowadza cenę końcową do wartości 2740 euro, wciąż dużo drożej od laptopa Apple’a.

Dodatkowo trzeba powiedzieć, że na laptopie Apple można bez problemu odpalić praktycznie dowolny system (w tym Windows!) czego nie można powiedzieć o DELL’u. Przynajmniej legalnie nie jest możliwe aby postawić na nim system Mac OS-X. Na MBP można też odpalać programy Windowsowe nawet bez posiadania w ogóle Windowsów dzięki programom takim jak Wine lub, dla tych co cenią sobie prostotę – CrossOver. W sumie więc, nie widzę żadnego sensu aby kupować laptopa pecetowego. Pod praktycznie każdym względem przegrywa z laptopem Apple’a. Ci, co kupują blaszakowe laptopy to frajerzy bo przepłacają za sprzęt o mniejszych możliwościach. No chyba, że potrzebują laptopa z niższej półki, wolniejszego i tańszego. Apple po prostu nie oferuje laptopów w tym segmencie. I tyle.

Dlaczego ludzie więc twierdzą, że laptopy Apple’a są droższe? Moim zdaniem, jest tak z kilku powodów.

1. Ci co tak twierdzą, nigdy nie zadali sobie trudu aby faktycznie porównać ceny jakiegoś laptopa o podobnych parametrach i powtarzają gdzieś zasłyszane ploty z dawnych lat (kiedy Apple był faktycznie droższy),

2. Niektórzy porównują ze sobą laptopy należące do zupełnie innej półki. Porównują MBP z jakimiś nędznymi Acerami i innymi laptopami z niskiej półki (tzn. o gorszym hardware i wyposażeniu). Jest to tak samo idiotyczne jak porównywanie Harleya z hulajnogą.

3. Porównują ceny z różnych krajów. Np. cenę laptopa w USA z ceną innego laptopa w Polsce. To zupełnie nie ma sensu. Aby porównanie miało sens, należy porównywać obu ceny w tym samym kraju.

Czy MBP jest tani? Oczywiście, że nie. Ale przecież żaden laptop w tej klasie nie jest tani. Czy jest droższy od odpowiedników PC? Nie. Cena jest typowa dla laptopów z tej półki lub niższa (na korzyść MBP).

Aktualizacja

Czy tylko laptopy Apple’a są tańsze? Niekoniecznie. Dla odmiany porównałem podobne sprzętowe konfiguracje desktopów (też w Irlandii), czyli

MacPro vs DELL Precision T5500

No to porównajmy…

DELL Precision T5500

Obudowa desktop+IEEE 1394b
OS: (English) Genuine Windows Vista® Ultimate x64 SP1 Media
Procesor: Intel® Xeon® Processor X5550 (2.66GHz,8MB L3, 6.4GT/s, 95W,QC)
Grafika: Nvidia Quadro FX580 512MB
Pamięć: 3GB DDR3 1066MHz ECC-UDIMM (3×1GB)
1TB (7200 RPM) SATA 3.0Gb/s Hard Drive with NCQ and 16MB DataBurst Cache
16xDVD+/-RW Drive 16xDVD/-RW Drive for Vista Ultimate 32Bit-64Bit with Roxio (PowerDVD in OS)
Dell Black 2 Button USB Optical Mouse
no sound

CENA KOŃCOWA (z VAT i przesyłką): 3526 euro

MacPro

Ten sam procesor, pamięć i dysk,
Grafika: ATI Radeon HD 4870 512MB
One 18x SuperDrive
Apple Mighty Mouse
AirPort Extreme Wi-Fi Card with 802.11n
wbudowany dźwięk

CENA KOŃCOWA (z VAT i przesyłką): 2643 euro

Atak na zabezpieczenia protected/private Javy/Scali i PHP5

Sun, 21 Jun 2009 05:45:00 +0200

Być może jednym z argumentów, dla których Ruby znajduje więcej zainteresowania ze strony programistów Javy niż Python, jest podobny mechanizm zabezpieczenia dostępu do atrybutów klasy za pomocą słów kluczowych private i protected. W języku PHP 5 wprowadzono podobny mechanizm. Ci jednak, którzy myślą, że te kwalifikatory zakresu dostępu stanowią jakiekolwiek poważne zabezpieczenie, są w głębokim błędzie. W banalny sposób można to obejść zarówno w w PHP 5, jak i w Javie. Przy czym o ile, w Javie wynika to raczej z celowego projektu w mechanizmie refleksji, w PHP 5 wygląda to na dziurę bezpieczeństwa…

Aby przełamać zabezpieczenia dostępu do atrybutów private i protected w wypadku Javy wystarczy użyć refleksji. W związku z tym, że Scala korzysta z tego samego mechanizmu refleksji co Java, problem ten dotyczy tak samo Scali. Poniższy kod wyświetla wartości atrybutów private i protected.

   
import java.lang.reflect.{Field}

class SecureData  {
  private val priv = "my-private-value" 
  protected val prot = "my-protected-value" 
}

object Main {
  def main(args:Array[String]) {
    val obj = new SecureData()
    for(f <- obj.getClass.getDeclaredFields) {
      f.setAccessible(true)
      println(f.getName+"="+f.get(obj))
    }
  }
}

Powyższy kod nie jest jakimś hackerskim zabiegiem. Jest zwykłym użyciem tego co daje refleksja. Tzn. domyślnie metoda setAccessible pozwala zmienić dostęp do tych atrybutów (można to samo zrobić z metodami), o ile nie podejmiemy specjalnych działań zapobiegawczych poprzez użycie np. SecurityManagera.

W PHP 5 użycie refleksji nic nie pomoże, bo nie ma tam metody setAccessible. Jednakże, na skutek błędów w implementacji PHP 5 (sprawdzane włącznie z najnowszym, wydanym 2 dni temu, PHP 5.3 RC4) złamanie zabezpieczeń tego języka jest też bardzo łatwe. Poniższa funkcja expose wyświetli każdy atrybut danej instancji klasy, bez względu na to czy atrybut ten jest chroniony kwalifikatorem protected czy private.

<?php
class SecureData {
  private $priv="my-private-value";
  protected $prot="my-protected-value";
}

function expose($obj, $attr_name) {
  $a = (array)$obj;
  $r = new ReflectionProperty($obj, $attr_name);
  if ($r->isPrivate())
    return $a["\0".get_class($obj)."\0".$attr_name];
  elseif ($r->isProtected()) 
    return $a["\0*\0".$attr_name];
  else 
    return $obj->$attr_name;
}

$c = new SecureData;
echo expose($c, 'priv'); # => my-private-value
echo expose($c, 'prot'); # => my-protected-value
?>

Można też iść “na całość” i zmodyfikować treści udostępnianie przez te atrybuty, co może być trochę katastrofalne w skutkach. Wystarczy zamiast rzutowania do array’a użyć metody settype. Jedyną wadą jest to, że po użyciu settype zniszczona została cała informacja o klasie i interfejsie obiektu.

<?php
function hack(&$obj, $attr_name, $value) {
  $r = new ReflectionProperty($obj, $attr_name);
  $class = get_class($obj);
  settype($obj, 'array');
  if ($r->isPrivate())
    $obj["\0$class\0".$attr_name] = $value;
  elseif ($r->isProtected()) 
    $obj["\0*\0".$attr_name] = $value;
} 

$c = new SecureData;
hack($c, 'priv', 'my-hacked-private-value'); 
var_dump($c);
/*
array(2) {
  ["Cpriv"]=>
  string(23) "my-hacked-private-value" 
  ["*prot"]=>
  string(18) "my-protected-value" 
} 
*/
?>

Na tym tle stanowisko Pythona nie brzmi wcale aż tak źle. W Pythonie wszystkie metody i atrybuty są publiczne. Jeśli programista chce to ma dostęp do wszystkiego. I tak przecież będzie miał taki dostęp jak się uprze, więc po co mu utrudniać życie, prawda? Wg filozofii Pythona, jedyną zaletą posiadani takich kwalifikatorów dostępu byłoby to, aby uniknąć pomyłki a nie, aby bić programistę po łapach. W Pythonie rozwiązano to za pomocą tzw. “manglingu” nazw. Otóż metody (i atrybuty) których nazwy zaczynają się od dwóch znaków podkreślenia (ale równocześnie nie mogą się kończyć takimi znakami) są traktowane specjalnie przy próbie uzyskania do nich dostępu. Tzn. formalnie nadal są public (tak jak wszystko inne), trzeba jednak użyć trochę innej, lekko zamotanej, składni. I to jest wystarczające, aby programista się nie pomylił.

                   
class SecureData(object):
  __priv = "my-private=value" 
  _prot = "my-protected-value" 

try: 
  print SecureData.__priv
except AttributeError:
  print "Wrong syntax, you lame!" 

print SecureData._SecureData__priv 
# => my-private=value

Zobacz też

Hack any Java class using reflection attack

How to set SecurityManager and Java security policy programmatically

Scala i Lift on GAE

Mon, 13 Apr 2009 06:32:00 +0200

Google opublikowało listę języków i javowych frameworków dostępnych dla swojego GAE (Google App Engine). Na liście jest m.in. JRuby, Jython, Groovy i Scala. Z powodu ograniczeń dostępności do wątków i JDBC napisano, że Lift nie jest wspierany. Jak jednak można wyczytać z jednym ostatnich wątków na liście dyskusyjnej Scali, trochę pośpieszono się z tą informacją. Lift daje się odpalić na GAE (to jest fork do kodu źródłowego). Scala posiada dwa rodzaje Aktorów – opartych na natywnych wątkach OS oraz opartych na asynchronicznej pętli, bez użycia wątków. Lift nie potrzebuje więc obsługi wątków do swej pracy. Co do JDBC, to sprawa jest trochę mętna, bo udało się uruchomić Lifta na pamięciowej bazie H2. Być może ograniczenie Google’a dotyczy tylko baz relacyjnych?

Updated: Frameworks and libraries supported by Google App Engine Java : List

Projekt Eulera 17 - Ruby, Python, Scala

Sun, 05 Apr 2009 23:24:00 +0200

Na polskim forum RoR pojawiła się informacja o projekcie Eulera składającym się z różnych łamigłówek programistycznych. Na forum RoR przedstawiane są rozwiązania w języku Ruby. Istnieją też rozwiązania w języku Clojure. Takie projekty są dobrym pretekstem do poćwiczenia swoich umiejętności programowania.

Zadanie 17 brzmi następująco.

Jeśli liczby od 1 do 5 zapisać za pomocą ich (angielskich) słów: one, two, three, four, five, to wtedy użyte zostanie 3 + 3 + 5 + 4 + 4 = 19 liter. Gdyby wszystkie liczby od 1 do 1000 zapisać za pomocą słów to ile w sumie by użyto liter? Uwaga: nie należy liczyć spacji ani myślników. Np. liczba 342 (three hundred and fourty-two) zawiera 23 litery a liczba 115 (one hundred and fifteen) zawiera 20 liter. Łącznik “and” jest wymagany w jęz. angielskim.

Rozwiązane podesłane w Ruby:

def to_words(num)
  a0 = %w{ one two three four five six seven eight nine ten eleven twelve thirteen fourteen fifteen sixteen seventeen eighteen nineteen }
  a1 = %w{ twenty thirty forty fifty sixty seventy eighty ninety }
  case num
  when 1..19
    a0[num-1]
  when 20..99
    num % 10 != 0 ? "#{a1[(num-20)/10]}#{a0[num % 10 - 1]}" : a1[(num-20)/10]
  when 100..999
    num % 100 != 0 ? "#{to_words(num/100)}hundredand#{to_words(num % 100)}" : "#{to_words(num/100)}hundred" 
  when 1000
    "onethousand" 
  end
end

puts (1..1000).inject('') { |acc,n| acc << to_words(n)}.size

W Pythonie można by to samo zapisać w zwarty sposób jako

def to_words(num):
  a0 = 'one two three four five six seven eight nine ten eleven twelve thirteen fourteen fifteen sixteen seventeen eighteen nineteen'.split(' ')
  a1 = 'twenty thirty forty fifty sixty seventy eighty ninety'.split(' ')
  if 1<= num <= 19:  return a0[num-1]
  if 20 <= num <= 99: return  "%s%s" % (a1[(num-20)/10], a0[num % 10 - 1]) if num % 10 != 0 else a1[(num-20)/10]
  if 100 <= num <= 999: return "%shundredand%s" % (to_words(num/100), to_words(num % 100)) if num % 100 != 0 else "%shundred" % to_words(num/100)
  if num == 1000: return "onethousand" 

print sum([len(to_words(n)) for n in range(1,1001)])

Zaś w Scali odpowiednikiem mógłby być kod:

def to_words(num: Int): String = {
  val a0 = "one two three four five six seven eight nine ten eleven twelve thirteen fourteen fifteen sixteen seventeen eighteen nineteen".split(' ')
  val a1 = "twenty thirty forty fifty si6xty seventy eighty ninety".split(' ')
  if (1 to 19 contains num) return a0(num-1)
  if (20 to 99 contains num) return if (num % 10 != 0) "%s%s".format(a1((num-20)/10), a0(num % 10 - 1)) else a1((num-20)/10)
  if (100 to 999 contains num) return if (num % 100 != 0) "%shundredand%s".format(to_words(num/100), to_words(num % 100)) else "%shundred".format(to_words(num/100))
  if (num == 1000) "onethousand" else "" 
}

println((for(n <- 1 to 1000) yield to_words(n).length).foldLeft(0)(_ + _))

Kod

1 to 19 contains num

to zapis w notacji operatorowej odpowiadający

(1.to(19)).contains(num)

Warunek logiczny if zwraca wartość którą można przypisać do zmiennej. for() jest też wyrażeniem. Słówko yield powoduje, że całość jest zwracana jako lista. Z kolei kod

for(n <- 1 to 1000) yield to_words(n).length

można by zapisać w Pythonie za pomocą wyrażenia listowego

[len(to_words(n)) for n in range(1,10001)]

zaś w Ruby byłoby to

(1..1000).map{|n| to_words(n).size}

Z powyższego kodu można by wyrzucić uprościć warunki logiczne. Poza tym możemy nie chcieć, aby zmienne a0 i a1 były inicjowane przy każdym uruchomieniu funkcji. Poza tym Scala posiada świetny mechanizm znany w z języków funkcyjnych – pattern matching. Zatem w innej wersji, rozwiązanie mogłoby wyglądać następująco:

def to_words(num: Int): String = num match {
  case n if n <= 19 => a0(n-1)
  case n if n <= 99 => if (n % 10 != 0) "%s%s".format(a1((n-20)/10), a0(n % 10 - 1)) else a1((n-20)/10)
  case n if n <= 999 => if (n % 100 != 0) "%shundredand%s".format(to_words(n/100), to_words(n % 100)) else "%shundred".format(to_words(n/100))
  case _ => "out of 1..1000" 
}                                           

val a0 = ("one two three four five six seven eight nine ten eleven twelve thirteen fourteen fifteen sixteen seventeen eighteen nineteen").split(' ')
val a1 = "twenty thirty forty fifty sixty seventy eighty ninety".split(' ')

println((for(n <- 1 to 1000) yield to_words(n).length).foldLeft(0)(_ + _))

Pewnym problemem jest to, że definicje zmiennych a0 i a1 które są wystawione na zewnątrz. Można to ominąć poprzez użycie funkcji jako obiektu i stworzenie w nim wewnętrznej metody.

  def to_words = {
    val a0 = ("one two three four five six seven eight nine ten eleven twelve thirteen fourteen fifteen sixteen seventeen eighteen nineteen").split(' ')
    val a1 = "twenty thirty forty fifty sixty seventy eighty ninety".split(' ')                

    def res(num: Int): String = num match {
      case n if n <= 19 => a0(n-1)
      case n if n <= 99 => if (n % 10 != 0) "%s%s".format(a1((n-20)/10), a0(n % 10 - 1)) else a1((n-20)/10)
      case n if n <= 999 => if (n % 100 != 0) "%shundredand%s".format(res(n/100), res(n % 100)) else "%shundred".format(res(n/100))
      case n if n == 1000 => "onethousand" 
      case _ => "out of 1..1000" 
    }
    res _
  }

Taki kod uruchomi inicjację listy słów tylko raz. Jednakże Scala pozwala na bardziej idiomatyczny zapis.

val to_words: Int => String = {
  val a0 = ("one two three four five six seven eight nine ten eleven twelve thirteen fourteen fifteen sixteen seventeen eighteen nineteen").split(' ')
  val a1 = "twenty thirty forty fifty sixty seventy eighty ninety".split(' ') 

  (num: Int) => num match {
    case n if n <= 19 => a0(n-1)
    case n if n <= 99 => if (n % 10 != 0) "%s%s".format(a1((n-20)/10), a0(n % 10 - 1)) else a1((n-20)/10)
    case n if n <= 999 => if (n % 100 != 0) "%shundredand%s".format(to_words(n/100), to_words(n % 100)) else "%shundred".format(to_words(n/100))
    case n if n == 1000 => "onethousand" 
    case _ => "out of 1..1000" 
  }
}

W tym wypadku użyto mechanizmu zarówno obiektowego (funkcja jest obiektem) jak i funkcyjnego (pattern matching).

O Scali można sobie podyskutować na polskich kanałach IRC #ruby.pl i (nowo powstałym) #scala.pl (oczywiście anglojęzyczny kanał #scala jest również bardzo pomocny).

Scala - język przyszłości

Sat, 28 Mar 2009 07:17:00 +0100

Kiedy zapytano Jamesa Goslinga (twórcę Javy) o to, który z języków programowania współpracujących z JVM (wirtualną maszyną Javy) by użył teraz, pomijając samą Javę, odpowiedź była zaskakująco szybka i bardzo jasna – Scala.

Nazwa “Scala” pochodzi od “Scalable language” (język skalowalny). Język ten nadaje się równie dobrze do krótkich, zwartych skryptów jak i do tworzenia wydajnych, ogromnych, bezpiecznych systemów sieciowych. W swych założeniach Scala nawiązuje do minimalizmu składni Lispa i Smalltalka (większość rzeczy oparta jest na bibliotekach a nie na składni) dzięki czemu język ten praktycznie nie ma ograniczeń rozwoju i doskonale się skaluje (w miarę potrzeb można tworzyć nowe typy i całe nowe struktury wyglądające jak nowa składnia języka).

Scala jest językiem kompilowanym do bytecodu JVM dzięki czemu potrafi się integrować w sposób praktycznie przezroczysty, z całą platformą Javy (istnieje co prawda implementacja Scali dla platformy .NET ale jest jeszcze niedojrzała). W Scali mamy też wygodną konsolę do interaktywnego testowania kodu (tak jak to jest w Pythonie i Ruby). W Scali każda wartość jest obiektem, każda funkcja zwraca wartość. Zatem każda funkcja też jest obiektem (first class object). Funkcje są też obiektami wyższego rzędu (higher order kinds), można je zagnieżdżać, przekazywać w parametrach, a nawet stosować mechanizm dziedziczenia.

Java jako platforma i jako język

Słowo “Java” oznacza z jednej strony język programowania, z drugiej platformę JVM. Sam język Java jest co prawda prosty, ale też dosyć toporny. Nic dziwnego, że pada wiele słów krytyki pod jego adresem. Co innego platforma Javy. JVM jest dopracowana, stabilna i szybka (ze swoim HotSpotem potrafi pobić kod napisany w języku C). Biblioteki są dojrzałe i używane masowo w biznesie i instytucjach finansowych. Każda nowość błyskawicznie znajduje swoje odzwierciedleniew Javie (ilość projektów w Javie wielokrotnie przewyższa to, co jest dostępne dla platformy .NET). Platforma Javy mocno prze do przodu i zwiększa stale swoją pozycję. Wydaje się tylko, że sam język nie za bardzo nadąża za tymi zmianami.

Gdy Microsoft “wyskoczył” ze swoją koncepcją .NET umożliwiającą tworzenie aplikacji na tą platformę w kilku językach a nie “jedynym prawidłowym”, można było odebrać to jako prztyczek w nos dla starej doktryny lansowanej kiedyś w środowisku Javy (jako jednego języka do wszystkiego). W rzeczy samej, patrząc dziś, Microsoft ze swymi językami zgodnymi z CLR niczym specjalnym nie zachwyca. Po pierwsze, istnieje dziś już ok. 240 różnych języków zgodnych z platformą Javy (jakieś 5x tyle co dla CLR). Javowe implementacje powstały nawet do języków dynamicznie typowanych (Groovy) oraz takich jak Python (Jython), Ruby (JRuby), JavaScript (Rhino) czy PHP (Quercus).

Po drugie, w przeciwieństwie do .NET, Java jest prawdziwie multiplatformowa (istnieje co prawda projekt Mono, ale wciąż odstaje jakością od windowsowego .NET). Mówiąc krótko, platforma Javy trzyma się mocno. Ale sam język jest przestarzały i wszyscy się zastanawiają nad tym, co by mogło go zastąpić. Moim zdaniem, coraz więcej wskazuje, że tym językiem może być Scala. (Swoją drogą język Java tak całkiem to pewnie nigdy nie zniknie. Raczej zredukuje się do miana assemblera XXI wieku. Zresztą już dziś tak wielu myśli o Javie, jako o assemblerze dla JVM)

Scala jako pure OOP

Scala jest językiem obiektowym w stopniu większym niż Java. W Scali nie ma sztucznego podziału na obiekty i typy prymitywne (int, float, string). Każda wartość jest w Scali pełnym obiektem (choć pod spodem kompilator Scali, tam gdzie się da, sam dokonuje inteligentnych konwersji na javowe prymitywy).

Każdy operator jest też metodą. Np. zapis 1 + 2 odpowiada dokładnie temu samemu co (1).+(2). Innymi słowy obiekt “1” używa tu metody ”+” operującej na parametrze będącym obiektem “2”. A to, że można opuścić nawiasy związane jest z tzw. notacją operatorową jaka jest możliwa Scali. O ile Ruby pozwala opuszczać nawiasy w niektórych sytuacjach (w definicji i wywołaniu metody), to Scala pozwala na opuszczanie ich w wypadku każdej metody pomiędzy dwoma wyrażeniami. W efekcie Scala pozwala na pisanie testów BDD przypomijących jeszcze bardziej język naturalny niż RSpec do Ruby’ego (też scalaz, scalatest). Także tworzenie nowych języków specjalnego zastosowania, tzw. DSL’i, dzięki notacji operatorowej wyglądają w Scali ładniej niż w Ruby. W ramach żartu pokazującego elastyczność składni Scali napisano nawet interpreter języka BASIC.

W Scali, w przeciwieństwie do Javy, nie ma też statycznych metod ani zmiennych (żałosne jest to, że tak nieobiektowe konstrukcje w ogóle wprowadzono do PHP). Zamiast nich Scala używa singletonów i metod klasowych. Oczywistą przewagą takiego podejścia jest m.in. możliwość dziedziczenia.

Podczas gdy Ruby i Python trzymają definicje metod klasowych i instancji razem, Scala trzyma je zgrupowane oddzielnie.

# Python:
class C(Object):
    def metoda_instancji(self):
        return "Jestem metodą instancji" 
    @classmethod
    def metoda_klasowa(cls):
        return "Jestem metodą klasową" 
print C.metoda_klasowa()
print C().metoda_instancji

# Ruby:
class C
  def self.metoda_klasowa
    "Jestem metodą klasową" 
  end
  def metoda_instancji
    "Jestem metodą instancji" 
  end                       
end
puts C.metoda_klasowa
puts C.new.metoda_instancji

# Scala
class C {
  def metoda_instancji = 
    "Jestem metodą instancji"    
}          
object C {
  def metoda_klasowa = 
    "Jestem metodą klasową" 
} 
println((new C).metoda_instancji)
println(C.metoda_klasowa)

Scala jako język statycznie typowany z inteligentną inferencją typów

Scala jest językiem statycznie typowanym. Z pewnością ucieszy to tych, co nie chcą pisać tony dodatkowych testów jednostkowych. Statyczna kontrola typów zapewnia większą kontrolę nad kodem. Można się zdziwić, jakim cudem przedstawiony wyżej kod działa, skoro nie ma w nim żadnej deklaracji typów. Właściwie to powyższa deklaracja klas i singletonu formalnie wygląda tak

class C {
  def metoda_instancji(): String = 
    return "Jestem metodą instancji";
}          
object C {
  def metoda_klasowa(): String = 
    return "Jestem metodą klasową";
}

Jednak nie trzeba pisać tak rozwleklego kodu. Scala posiada wyrafinowany mechanizm inferencji typów pozwalający na ograniczenie niepotrzebnego deklarowania typów w wypadkach kiedy kompilator jest w stanie to sobie samemu wywnioskować (podobną inferencję typów stosują inne języki, np. Haskell).

W Scali także (podobnie jak w Ruby czy JavaScript) końcowe średniki zamykające wyrażenie można pominąć, nawiasy dla metod bez parametrowych są opcjonalne i nie trzeba używać komendy return aby zwrócić wartość z metody. W Scali (podobnie jak w Ruby) zawsze zwracana jest ostatnia wartość wyrażenia.

Scala, podobnie jak Java i Ruby, nie posiada dziedziczenia wielobazowego. W przeciwieństwie do Javy, Scala nie posiada interfejsów. I bardzo dobrze, bo ich przydatność jest wysoce wątpliwa (oczywiście do PHP5 dodano bezmyślnie te nieszczęsne interfejsy). Ich główną wadą jest to, że nie mogą posiadać żadnej implementacji ani deklaracji zmiennych. Z kolei klasy abstrakcyjne w Javie mogą posiadać częściową implementację, ale nie można dziedziczyć po wielu klasach abstrakcyjnych tylko po interfejsach które nie mają żadnej implementacji. Bardzo niewygodne. Scala rozwiązuje ten problem za pomocą traits. Traits działają podobnie do modułów w Ruby. Nie mają konstruktorow ani nie można stworzyć ich instancji więc odpada efekt konfliktu kolejności konstruktorów. Traits mogą jednak podlegać dziedziczeniu, mogą mieć częściową lub pełną implementację metod, oraz mogą posiadać zadeklarowane zmienne. I każda klasa może dziedziczyć po kilku traitsach. Proste i wygodne.

Niejawne konwersje (implicit conversion)

Idea niejawnych konwersji nie jest w zasadzie niczym nowa. Występuje już w języku C. Gdy dodawane są dwie zmienne o typach short i long to ta pierwsza zostaje domyślnie przekształcona do long. Nie trzeba wykonywać żadnego jawnego rzutowania typu.

Scala idzie dalej. Za pomocą mechanizmu implicit conversions potrafi uzyskać efekty podobne jak w Ruby, ale bardziej bezpieczne. Zobaczmy jednak wpierw jak to się robi Ruby (który wykorzystuje swoją koncepcję otwartych klas).

class Integer
  def kb
    self * 1024
  end     
  def mb
    self * 1024 * kb
  end  
end                   

class String 
  def welcome
    "Hello " + self
  end
end

puts 10.kb # => 10240
puts 10.mb # => 10485760
puts "Jarek".welcome # => Hello Jarek

Co prawda Ruby potrafi “zamrozić” swoje obiekty uniemożliwiając ich modyfikację

Fixnum.freeze

class Integer
  def kb
    self * 1024
  end
end   
# => TypeError: can't modify frozen class

ale technika ta (zwana też trochę niepoprawnie jako “monkey patching”) jest używana dosyć powszechnie w Ruby. Główną jej wadą jest to, że takie zmiany w klasach są globalne i to może prowadzić do różnych nieporozumień w innych częściach kodu.

Scala nie ma tego problemu. Pozwala na uzyskanie podobnych efektów bez konieczności globalnych zmian w obiekcie. Zamiast otwierania klas, Scala dodaje definicje niejawnych konwersji. Jeśli wywołujemy metodę obiektu której on nie posiada, Scala patrzy na leksykalny kontekst definicji dostępnych konwersji dla danego typu (jak pamietamy, Scala jest językiem statycznie typowanym). Jeśli znajdzie sygnaturę metody taką jak nazwa wywoływanej metody, użyje jej tak jakby należała do obiektu.

class StrConvert(s: String) {
  def welcome = "Hello " + s
}                         

class IntConvert(x: Int) {
   def kb = 1024 * x
   def mb = x * 1024 * kb
}                    

implicit def str_convert(s: String) =  new StrConvert(s)
implicit def int_convert(i: Int) =  new IntConvert(i)

println(10.kb)
println(2 mb)
println("Jarek" welcome)

Kropki w wywołaniach metod są oczywiście w Scali opcjonalne ze względu na notację operatorową.

Niejawne konwersje Scali przydają się w wypadku korzystania z cudzego kodu. Nie musimy (tak jak w Ruby) ingerować i zmieniać cudzych bibliotek. Zamiast tego wystarczy dodać lokalne definicje niejawnych konwersji typów. Przykładem toporności i ograniczeń Javy jest konieczność korzystania z innej składni do operacji na typach BigInteger. Jeśli początkowo pisaliśmy kod używający zwykłych typów int to w wypadku kiedy musi on operować na większych liczbach, czeka nas niezła refaktoryzacja kodu a kod mógłby wyglądać mniej więcej tak jak poniższy kod (przykład dotyczy składni Scali w ktorej też można pisać po “javowemu”)

                        
import java.math.BigInteger 

def factorial(x: BigInteger): BigInteger = 
 if (x == BigInteger.ZERO) 
   BigInteger.ONE 
 else 
   x.multiply(factorial(x.subtract(BigInteger.ONE)))

Dzięki możliwościom implicit conversion, znacznie wygodniej jest pisać tak:

def factorial(x: BigInt): BigInt = 
 if (x == 0) 1 else x * factorial(x - 1)

Warto zwrócić uwagę, że to nie jest jakaś dodana nowa składnia do Scali. Wrapper do BigInt jest stworzony w bibliotece. Nie trzeba żadnego przebudowania kodu Scali tak, jak to musi być uczynione w innych językach.

Scala jako język funkcyjny (FP)

Mam wrażenie, że programowanie funkcyjne przeżywa jakiś swój renesans. Od jakiegoś czasu więcej słychać o Erlangu, Clojure (świetny dialekt Lispa w Javie), Haskellu czy F#. Zalety programania funkcyjnego w stosunku do programowania imperatywnego są znane. Przede wszystkim, brak zmiennych i brak efektów ubocznych. Odpadają problemy związane z synchronizacją wątków, semaforami i blokowaniem dostępu do wspólnych obszarów pamięci. Kod pisany funkcyjnie znacznie łatwiej jest też testować. Funkcja niczym ma tylko jedno wejście i jedno wyjście. Nic innego ukradkiem nie zmieni. Programowanie funkcyjne jest też prostsze, choć osoby spaczone latami spędzonymi na programowaniu imperatywnym, mogą mieć na początku pewne problemy z przestawieniem sposobu myślenia. Np. w typowo funkcyjnym podejściu nie ma w ogóle pętli w programie. Zastępuje ją rekursja (która nie przepełnia stosu, jest to tzw. tail recursion)

Przykład różnic w podejściu imperatywnym oraz funkcyjnego dla Ruby’ego i Scali.

Ruby:

# Podejście imperatywne:

class Imper
  attr_accessor :x, :y
  def initialize(x,y)
    @x, @y = x, y
  end     
  def move_by(dx, dy)
    @x += dx
    @y += dy
  end
  def show
    puts "x:#{x}, y:#{y}" 
  end
end                                                                

x = Imper.new(1,2)
x.move_by(3,4)
x.show

# To samo funkcyjnie:

class Func
  attr_reader :x, :y
  def initialize(x,y)
    @x, @y = x, y
  end     
  def move_by(dx, dy)
    Func.new(@x+dx, @y+dy)
  end
  def show
    puts "x:#{x}, y:#{y}" 
  end
end

x = Func.new(1,2)
x = x.move_by(3,4)
x.show        

# lub to samo, ale bez tworzenie zmiennych:

Func.new(1,2).move_by(3,4).show

Scala:

                          
// Kod w stylu imperatywnym:

class Imper(x: Int, y: Int) {
  var iks: Int = x
  var igrek: Int = y           
  def move_by(dx: Int, dy: Int) {
    iks += dx
    igrek += dy
  }
  def show {
    println(iks,igrek)
  }
}                 
val p = new Imper(1,2)
p.move_by(3,4)
p.show

// i to samo funkcyjnie:

class Func(x: Int, y: Int) {
  val iks: Int = x
  val igrek: Int = y           
  def move_by(dx: Int, dy: Int) = new Func(iks+dx, igrek+dy)
  def show {
    println(iks,igrek)
  }
}                 
(new Func(1,2)).move_by(3,4).show

Obiekty deklarowane jako val są niemutowalne, nie można zmienić ich wartości (odpowiadają javowej deklaracji final). Z kolei deklaracja var oznacza zmienne mutowalne, mogące zmienić swoją wartość.

Kod pisany funkcyjnie, może być znacznie krótszy, prostszy i tym samym mniej podatny na błędy. Zobaczmy, jak bardzo można zredukować w Scali kod napisany w stylu imperatywnym do funkcyjnego (przykład z książki “Programming in Scala”)

                          
def printArgs(args: Array[String]): Unit = { 
  var i = 0 
  while (i < args.length) { 
    println(args(i)) 
    i += 1 
  } 
}

Pozbywamy się zmiennej var:

                          
def printArgs(args: Array[String]): Unit = { 
  for (arg <- args) 
    println(arg) 
}

To samo, inaczej wyrażone:

                          
def printArgs(args: Array[String]): Unit = { 
  args.foreach(println) 
}

Metoda nie jest jeszcze “czysto” funkcyjna bo posiada efekt uboczny w postaci drukowania wartości w funkcji println. Pozbywamy się więc i jej.

                          
def formatArgs(args: Array[String]) = args.mkString("\n")

Wywołanie:

                          
println(formatArgs(args))

Warunki zwracające wynik

W Scali warunki logiczne także zwracają wartość. Weźmy na przykład kwestię operatora trynarnego. W wielu językach można spotkać (odziedziczoną po C) następującą składnię:

                          
wynik = warunek ? wyrazenie1 : wyrazenie2

Przez wiele lat w Pythonie trzeba było pisać w taki sposób:

                          
if warunek:
    wynik = wyrazenie1
else:
    wynik = wyrazenie2

Pod naciskiem społeczności, Guido van Rossum dodał w końcu odpowiednik takiej konstrukcji i teraz można pisać tak:

                          
wynik = wyrazenie1 if warunek else wyrazenie2

Tymczasem w Scali taki problem jest zupełnie sztuczny. Skoro warunek zwraca wynik, to nie trzeba wymyślać żadnej nowej składni naśladującej język C. Wystarczy po prostu napisać:

                          
val wynik = if (warunek) wyrazenie1 else wyrazenie2

Ogólnie, cała Scala promuje podejście funkcyjne, ale nie zmusza do niego. Scala nie stosuje oddzielnych nazw dla wersji mutowalnej i niemutowalnej. Dzięki temu unika się niepotrzebnego refactoringu kodu w wypadku potrzeby zmiany jednej wersji na drugą.

Domyślnie typy są niemutowalne.

                          
scala> val x = Map[Int, String]() 
# => x: scala.collection.immutable.Map[Int,String] = Map()

Aby mieć tym mutowalny, trzeba to jawnie wskazać.

                          
scala> import scala.collection.mutable.Map
scala> val x = Map[Int, String]()         
# => x: scala.collection.mutable.Map[Int,String] = Map()

Lift – komponentowy framework w Scali

Mówiąc o Scali nie sposób nie wspomnieć o świetnym frameworku webowym jakim jest Lift. Framework ten inspirowany jest różnymi frameworkami (głównie Wicket’em ale też Django, Rails czy smalltalkowym Seaside). Lift jest przede wszystkim frameworkiem komponentowym (odcina się tu od klasycznego modelu MVC promowanego przez Rails). Podejście komponentowe ma przewagę nad MVC, dużo lepiej się nadaje do złożonych aplikacji (innym przykładem dobrego podejścia komponentowego jest pythonowy CMS – Plone.

Lift Book – darmowa, dostępna online (najnowsza wersja PDF jest na dole strony: http://groups.google.com/group/the-lift-book)
Exploring Lift: Scala-based Web Framework – książka (dostępna jeszcze w wersji roboczej)
David Pollak On Lift Framework and Scala
Derek Wischusen on Integrating Flex, BlazeDS and Scala/Lift

Inne frameworki:

Podsumowując.

Scala to nowoczesny język będący hybrydą pure OOP i FP, statycznie typowany ale z inteligentną inferencją typów, o bardzo elastycznej składni i kompilowana do bytecodu JVM. Dzięki zaawansowanej inferencji typów i implicit conversions nie odczuwa się narzutu związanego z faktem że Scala jest statycznie typowana (a dostaje zalety ściślejszej kontroli kodu). Scala nie ma operatorów, operatory są zwykłymi metodami definiowanymi w bibliotekach.

Jednak tym co jest największym atutem Scali to jej minimalizm składniowy. Scala umożliwia tworzenie nowych typów i struktur językowych bez konieczności zmian w samej zasadniczej składni języka. To oznacza, źe podobnie jak Lisp, Scala nie ma praktycznie żadnych ograniczeń w rozwoju. Tym samym Scala jest w stanie przetrwać różne tendencje i upodobania składniowe i “przeskalować” się do nowych potrzeb.

Scalę używa już gdzieś parę banków w UK. Na Scalę niedawno przeszedł Twitter, ma wkrótce przejść też Github.

Linki

Maglev - w tym roku?

Tue, 17 Mar 2009 04:09:00 +0100

Po początkowym szumie wokół Magleva, sprawa na jakiś czas przycichła i wiele osób powątpiewało czy jego twórcom uda się spełnić to co zapowiadali. Gdyby im się udało, Ruby uzyskałby fantastyczną platformę. Dojrzałą i szybką (rozwijana od ponad 20 lat i sprawdzoną w zastosowaniach komercyjnych) wirtualną maszynę Smalltalka z wbudowanym mechanizmem wydajnej, przezroczystej, transakcyjnej persistent memory (nie wiem jak to oddać po polsku, a każdym razie rozwiązanie wygodniejsze nawet od obiektowej bazy danych, coś w stylu javowej Terracoty). Aktualnie kod Maglev’a jest cały czas w fazie alpha, ale na drugi kwartał roku 2009 zapowiada jest już wersja beta. To, co cieszy to rosnąca, coraz większa zgodność Maglev’a z Ruby Specs.

Rails 2.3

Tue, 17 Mar 2009 03:48:00 +0100

W końcu się doczekaliśmy finalnej wersji Rails 2.3 (oznaczona jest jako wersja 2.3.2 użytkownicy Passengera muszą sobie zrobić aktualizację do wersji 2.1.2). Cieszy może wsparcie do Rack’a i liczne usprawnienia frameworka, ale tak naprawdę to czekam raczej na następną wersję, jaką ma być Rails 3.0 (aka Merb 2.0). Ponoć na najbliższej konferencji Railsconf 2009 ma być jakaś wersja beta kodu źródłowego (w każdym razie 6 maja przewidziane są jakieś prezentacje na temat Rails 3). Mam nadzieję że stabilna wersja Rails 3 pojawi się szybko i nie będzie rozczarowaniem dla tych, co wcześniej cenili sobie prostotę i elastyczność Merba.

Dlaczego iWork'09?

Thu, 26 Feb 2009 02:42:00 +0100

Jakiś czas temu próbowałem skontaktować się z twórcami Django co do możliwości udostępnienia softu umożliwiającego wstawienie do sieci książki z mechanizmem zbierania komentarzy od internautów. W ten sposób dostępna jest Django Book. Niestety nigdy nie doczekałem się jakiejkolwiek odpowiedzi. Może to i dobrze, bo jest lepsze rozwiązanie…

Przypadkiem dziś odkryłem, że wydany przez Apple pakiet iWork’09 (mający być do pewnego stopnia konkurencją dla microsoftowego pakietu Office), poza całkiem niezłym procesorem tekstu Pages, dodał bardzo dobrą usługę umożliwiającą udostępnianie projektów dowolnym, zaproszonym osobom. Apple, w swoim stylu, zrobił to bardzo ładnie i prosto. Można w banalnie łatwy sposób udostępnić książkę online tylko do odczytu, z możliwością komentowania dowolnego jej fragmentu lub z możliwością załadowania jej treści w formacie iWork, PDF lub MS Word. O ile wcześniej raczej nie brałem pod uwagę pakietu iWork, to teraz, z nowym iWork’09 i sieciową usługą iwork.com wszystko uległo zmianie i oczywiście z miejsca zamówiłem iWork’09. :)

Tak swoją drogą, ci, co tak krytykują iPhone’a lub Macintoshe, jednej rzeczy nie rozumieją – siłą produktów Apple’a jest nie tylko ich duża prostota i intuicja obsługi, ale świetna infrastruktura Apple’a integrująca je wszystkie razem. iTunes, iPhone, AppStore, darmowy i doskonały XCode 3.x do tworzenia softu, mac.com aka me.com synchronizującym komputery, kalendarze, kontakty, zakładki przeglądarki Safari czy iPhone’a. I teraz iWork’09, zintegrowany z iwork.com… Te wszystkie produkty po prostu genialnie ze sobą współpracują.

Debugowanie Merba w Netbeans

Thu, 22 Jan 2009 04:30:00 +0100

Po paru godzinach walki z Netbeans, przeglądaniem źródeł, przekopywaniem list dyskusyjnych i zgłoszonym tickecie, w końcu udało mi się zmusić Merba do pracy z Netbeans. Mam też dobrą wiadomość, że Netbeans 7 (wersja trunk) w przyszłym tygodniu ma mieć dodane wsparcie do Merba (tworzenie projektów, debugowanie itp). Dla tych, co chcieliby już teraz móc debugować swoje projekty Merba w graficznym, ślicznym debugerze Netbeans, podaję instrukcję obsługi. :)

Krok 1: trzeba ściagnąć najnowszą wersję trunk ze strony http://bits.netbeans.org/download/trunk/nightly/latest/.

Od niedawna Netbeans posiada możliwość podpięcia swojego debugera do dowolnego kodu Ruby’ego za pomocą tzw. remote debugging (zobacz wpis w blogu Martin Krauskopfa z 11 listopada 2008 Remote Debugging: explore Ruby code easily). Właśnie tej metody użyjemy aby zmusić Netbeansa do pracy z Merbem.

Krok 2: w swoim pliku config/init.rb musisz ustawić opcję wymuszającą uruchamianie Merba tak jak Rails (trzeba wyłączyć forkowanie ładowania klas):

Merb::Config.use do |c|
  c[:fork_for_class_load] = false
  # ... reszta ustawień
end

Krok 3: musisz mieć zainstalowany gem ‘ruby-debug-ide’ i uruchomić zdalny nasłuch debuggera:

sudo gem install ruby-debug-ide

rdebug-ide -p 7000 `which merb`

Nie ma znaczenia jaki port ustawisz dla projektu Merba z poziomu konfiguracji projektu (prawy click na nazwę projekty -> Properties). Jeśli chcesz uruchomić Merba na porcie 3000 to po prostu odpal nasłuch debuggera przez podanie dodatkowych opcji:

rdebug-ide -p 7000 `which merb` -p 3000

Krok 4: Ustaw sobie w kodzie breakpoint, następnie podepnij debugger “menu -> Debug -> Attach Debugger…”

Nie używaj opcji “menu -> Debug -> Debug Main Project”. Nie ma ona tu znaczenia. Debugowanie odpala operacja przypisania debuggera.

Krok 5: Otwórz przeglądarke i uruchom projekt (http://localhost:4000)

Przełącz się na Netbeans. To wszystko.

Wbrew temu co piszą na Wiki do JRuby, nie ma potrzeby tworzenia pliku script/server zawierającego skopiowaną treść skryptu merb. Użytkownicy Windozy, którzy mają dostępu do komendy which, zamiast tego niech wpiszą po prostu merb, albo pełną ścieżkę do skryptu merb.