o Ruby

Stwierdzenie, że idea wolnego oprogramowania to wspaniała rzecz nie będzie zbyt odkrywcze. Na tej idei może skorzystać praktycznie każdy, niezależnie czy jest wielką korporacją, średnią lub małą firmą czy też "niedzielnym" koderem. Czyż to nie wspaniałe, że można zbudować praktycznie dowolnie skomplikowane oprogramowanie i nie trzeba za to płacić ogromnych pieniędzy?

Świat ten rządzi się swoimi prawami. Istnieje głównie dlatego, że są ludzie, którzy dzielą się swoim kodem (nie oszukujmy się, większość z nas tego nie robi), rzecz jasna tylko ten dobry jest zauważany i używany przez innych. Co lepsi urastają nawet do miana "celebrytów". Któż z programistów Rubiego nie zna takich osób jak Yehuda Katz czy też Ryan Bates (ten ostatni jest przykładem tego iż nie zawsze chodzi o oprogramowanie)?

Czytaj dalej...

Witam po kolejnej długiej przerwie. Ponieważ ostatnio nie za bardzo mam czas na pisanie porządnych wpisów (czyli takich gdzie muszę dobrze przemyśleć temat, poszperać w internecie, dodać swoje przemyślenia - a zajmuje dobre kilka godzin) to tym razem trochę w innym stylu. Bez kodu, bez przykładów. Ba, temat nawet nie będzie dotyczył Rubiego!

A jak nie chodzi o Ruby to chodzi o Git! Chciałbym podzielić się z Wami moimi spostrzeżeniami na temat tego narzędzia.

Czytaj dalej...

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