o Ruby

Muszę przyznać, że od zawsze uwielbiałem zadania, które wymagają myślenia, główkowania i kombinowania. W okresie mojej podstawówki dotyczyło to głównie rozwiązywania zadań z matematyki, potem (gdy tylko zetknąłem się z informatyką w LO) przeszło to na zadania algorytmiczne. To były zresztą moje początki z programowaniem i do dzisiaj mam ogromny sentyment do tej dziedziny informatyki.

Ostatnio na forum rubyonrails.pl zaproponowano, by rozwiązywać zadania ze strony o nazwie "Project Euler". Jak się okazało zadania są na pograniczu matematyki, logiki, kombinatoryki, algorytmiki i większość ma tę własność, że bez pomocy komputera nie da się ich rozwiązać.

To co mnie urzekło od samego początku to fakt, że nie zawsze chodzi o znalezienie najbardziej wydajnego rozwiązania. Nie ma bowiem narzuconego z góry żadnego limitu (na stronie musimy podać otrzymane rozwiązanie i sprawdzana jest jego poprawność). Często naiwne rozwiązanie wystarcza, co nie znaczy, że napisanie programu jest banalne! Barierą może być sam język, w którym piszemy. Sporo zadań wymaga obliczeń na dużych liczbach lub operowania danymi tekstowymi, co może okazać się bardzo niewygodne (nie mylić z "niemożliwe") w takich językach jak C/C++ czy Java. Z kolei te same zadania okazują się przysłowiową "bułką z masłem" jeśli użyjemy wysokopoziomowych języków, np. Ruby lub Python (jeśli oczywiści dana funkcjonalność występuje).

Czytaj dalej...

Przez ostatnie dni miałem okazję zapoznać się z biblioteką FFI. (Swoją drogą, kenai.com, czyli strona na której jest hostowany projekt, to próba stworzenia przez firmę Sun systemu, podobnego do sourceforge, githuba itp. Całość zupełnie za darmo, o pełnych możliwościach można poczytać na stronie projektu. Aplikacja jest oparta o framework Ruby on Rails i uruchamiana przy pomocy JRubiego.) Biblioteka FFI służy do łatwego łączenia kodu Rubiego z bibliotekami C.

Rozszerzenia w C - różne podejścia

Zanim opiszę zalety i sposób wykorzystania FFI, chciałbym napisać kilka zdań na temat samych rozszerzeń C dla Rubiego. Otóż istnieje kilka możliwości w tej kwestii. Jedną z podstawowych jest wykorzystanie wewnętrznego API interpretera Rubiego napisanego w C (popularnie zwanego MRI lub cRuby). Jeśli zaglądałeś kiedykolwiek w kod źródłowy MRI i widziałeś źródła np. pliku array.c, to kod takiego rozszerzenia pisze się praktycznie tak samo. Z tego też powodu jesteśmy zmuszeni do poznania, choćby w minimalnym stopniu, wewnętrznego API C Rubiego (zobacz http://www.eqqon.com/index.php/Ruby_C_Extension).

Aby ułatwić choć trochę tworzenie takich rozszerzeń powstał projekt RubyInline. Jego dwoma największymi zaletami jest możliwość osadzania kodu bezpośrednio w kodzie Rubiego, a także automatyczna kompilacja takiego kodu dopiero w momencie odpalenia (skompilowane rozszerzenie jest zapisywane w katalogu ~/.ruby_inline/ by nie kompilować go za każdym uruchomieniem). Pozostałe zasady zostają takie same (ciągle operujemy na tym samym API).

require "rubygems"
require "inline"

class MyMath
  inline do |builder|
    builder.c "
      long add(int a, int b) {
        return a + b;
      }"
  end
end
math = MyMath.new
puts math.add(100, 300)

400

Czytaj dalej...

Jednym z częstych pytań, jakie rodzą się wśród adeptów programowania w Ruby, jest kwestia znaków '?' i '!' w nazwach metod. Pojawiają się także wątpliwości czy Ruby traktuje jakoś specjalnie te znaki, czy stoi za nimi jakaś czarna magia. Nawet wśród bardziej doświadczonych programistów Rubiego zauważam, że nie zawsze poprawnie jest interpretowana idea tych znaków. Tym razem wyjaśnię te i inne wątpliwości związane z tymi dwoma znakami. Zapraszam zatem do lektury (nie tylko wspomnianych adeptów).

Pierwsza rzecz, na którą chciałem zwrócić uwagę jest fakt, że znaki te nie są w żaden specjalny sposób traktowane przez Ruby. Dla Rubiego to taki sam znam jak 'a', 'C', '0' czy '_'. Różnica jest tylko taka, że znak ten może występować tylko i wyłącznie na końcu nazwy (ale nie może być to jedyny znak w nazwie). Dlatego poprawne są nazwy zero?, deleted?, flatten!, map!, ale już nie foo?!, foo?bar, !bar itp.

ruby.awesome?

Na pierwszy rzut idzie łatwiejsza kwestia - pytajnik. Niepisana zasada mówi, że powinno się go używać dla metod, które są predykatami, czyli metodami które zwracają wartość true lub false. W innych językach najczęściej używa prefixu "is" w nazwie (np. is_active lub isDeleted). Oto kilka przykładów:

a = [1, 2, 3]
if a.include?(2)
  puts "Found!"
end

# przykład z rails
if request.post?
  # ...
end

user.awesome = user.active? && user.paid?

Czytaj dalej...

Wpis ten jest jedną z części cyklu pt "Nowości i zmiany w Ruby 1.9". Pełną listę wpisów znajdziesz pod adresem http://radarek.jogger.pl/2008/11/30/nowosci-i-zmiany-w-ruby-1-9/.

Disclaimer

Muszę przyznać, że nosząc się z zamiarem napisania tego artykułu miałem blade pojęcie o kodowaniach znaków, choć wcześniej nie zdawałem sobie z tego sprawy. Wydawało mi się, że znając takie pojęcia jak ASCII, Unicode i umiejąc z nich korzystać na co dzień, wiem sporo o kodowaniach. Trudno się jednak dziwić takiemu myśleniu, gdyż większość z Was, zapewne tak jak i ja, korzysta z 1-2 kodowań i póki działa nie musi wiedzieć dlaczego. Wertując ogromną ilość wiadomości na liście mailingowej ruby-core sporo dowiedziałem się, chociaż wciąż nie czuję się ekspertem w tej dziedzinie. Okazało się, że temat ten jest bardzo złożony i dotyczy wielu kwestii. Proszę mi zatem wybaczyć ewentualne niedociągnięcia, niezbyt dokładne opisanie niektórych z nich oraz dosyć chaotyczny styl.

Ruby 1.9 haz encodingz!

Kolejne zmiany jakie zaszły w wersji 1.9 Rubiego dotyczą obsługi kodowań znaków. Można bez przesady stwierdzić, że to najważniejsza ze zmian. Bądź co bądź mamy XXI wiek i brak natywnej obsługi kodowań jest niewybaczalny, a już na pewno nie przez środowisko "enterprise".

Jak zapewne wszyscy wiedzą, łańcuchy znaków w Ruby 1.8 to ciągi bajtów i nic więcej. Prowadzi to do oczywistych zachowań, jednak bardzo niewygodnych. Obrazuje to poniższy program:

s = "ąęć"
puts s.size

6

Czytaj dalej...

Wpis ten jest jedną z części cyklu pt "Nowości i zmiany w Ruby 1.9". Pełną listę wpisów znajdziesz pod adresem http://radarek.jogger.pl/2008/11/30/nowosci-i-zmiany-w-ruby-1-9/.

Zacznę od (jak mi się wydaje) najważniejszej zmiany. Chodzi mianowicie o zewnętrzne iteratory, których do tej pory jakby nie było. Napisałem jakby, ponieważ mogliśmy skorzystać z klasy Generator, która potrafiła przekonwertować wewnętrzny iterator na zewnętrzny. Niestety było to niewygodne, a przy okazji dość niewydajne (implementacja tej klasy jest oparta na kontynuacjach - sic!). Zewnętrzne iteratory przydają się podczas iteracji kilku kolekcji na raz, zwłaszcza jeśli nie posiadają dostępu indeksowego.

Czytaj dalej...