Tag: ruby

Swiss Tournament in Ruby

Posted by – 03/02/2010

Being a chess player (not a very good one), I’ve always been intrigued by Swiss Tournaments. They are so practical, and ensure that even a lowsy player like myself, can play the same number of rounds as any other player. That’s being inclusive!

I’ve played some knock-out tournaments (to me it meant being kicked off in the second or third round), and, given their nature, not-so-good players tend not to attend these tournaments (since their fun will, almost surely, end before long).

Well, to solve a very similar problem, but not in any game championship, a co-worker suggested we could use a Swiss Tournament system. I liked the idea, but not being sure it could really solve the problem, I had to quickly implement something to test our data with… so Ruby to the rescue!

In no time we were up and running, and apart from minor issues that were being fixed along the way, I guess it’s a pretty good implementation. You can checkout the code to get a feel of it. Of course, it doesn’t follow any rules from any Chess or Go association (Wikipedia, after all, was my guide here), but it serves our goal. Being a “proof-of-concept” code, feel free to improve it (just tell me about it, will you?).

Looking for a new programming language to learn

Posted by – 17/11/2009

I know it has been a long time since my last post. I am sorry about that, but life has it’s complications every now and then (as you know)… Well, on to the article.

Recently I had to reimplement in C a prefork server I wrote in Ruby for an internal project at Propus. Not that the Ruby version wasn’t enough (after all, although being in Ruby, I was using Unix plumbing, much in the fashion Ryan tell us about in the – now famous – I like Unicorn because it’s Unix article)… The problem is that, in one of our clients, the only version available for Ruby was 1.8.1.

Yeah… I know… But we were not allowed to upgrade and, although it didn’t seem at first, the same server presented a nasty memory leak in 1.8.1 that was not present in 1.8.7 and 1.9.1. I still don’t know where the problem is… I suspect some of the C-to-Ruby glues around TCP sockets might be blamed, but after a couple of days trying to figure it out, I decided it was easier just to reimplement it using C.

It actually took less than a day to get the C version going… nothing fancy and, apart from memory footprint, just the same functionality and about the same speed of the Ruby version. But it was enough to remind me I really don’t like all the scaffolding one has to raise in order to make something useful in C. It’s not just a matter of SLOC (of course, C version was more than 3 times longer than Ruby one)… I am talking about all the manual memory management, pointer operations and the disgusting experience of dealing with strings in C. I know some people are addicted to that sort of thing like heroin, but to me it just slows development.

This experience made me think about learning a second compiled programming language. I do some Perl, a lot of Python and (of course) most of my work in Ruby, but those are all interpreted languages. For compiled languages I always resorted to C… So I am officially looking for a language to learn.

So far, the best candidates are OCaml (I got a little excited about JoCaml a few months ago, now I might get serious about it), Haskell, Lisp, Objective-C, Ada, and Vala. Of these, I’ve been reading a lot about OCaml… It seems a fine and expressive language, with decent foundations, object-oriented extension, broad standard library and (with JoCaml) concurrency… Also it might give me the proper excuse to finally wrap my mind around a functional language!

People keep me pointing to Java and Erlang… Well… for using Java I would much prefer using JRuby. Erlang, ITOH, has a weird syntax (at least to me) and it seems much of what makes it great will, eventually, be part of Ruby (or already is using libraries) – either that or I’ll just wait for Reia to be ready. Besides, neither can be compiled to native code (ok, that argument can be stretched both ways, so just ignore it).

So, what do you think? Any advice?

Ruby versus Python

Posted by – 26/09/2009

This is not another rant to praise one in spite of the other (an everybody knows I love Ruby, so it would not be impartial), but sometimes people seems to live in another world and do things for the wrong reasons.

I just read this blog post by Kanwei Li in which he gives 2 or 3 reasons he ditched Ruby in favor of Python. First of all, both are great languages and, although I favor Ruby, I use Python for some projects and they are not all that different. Of course, everyone is free to choose which language one favors, but Kanwei seems to be “ditching” Ruby out of not knowing much about it, or out of preferring one style over the other…

His first “reason” is that in Python white spaces matter. I used to think this is just a matter of style, but every now and then mandatory alignment hurts me (just try to put together a code generator and you’ll notice it). Although my code is always correctly aligned, I like that it’s done so because I want it that way, and not because some language demands it. Rants and more rants have been written about Python’s mandatory alignment (or other languages lack of it), and I am not going through all of it… Just I don’t think it’s a good reason to ditch Ruby…

After, he makes a big deal out of Ruby’s ternary if. As written by him, he prefers

if len(a) > 0:
        v = a[0]
        a = a[1:]
        v = None

over Ruby’s ternary if

v = a.empty? ? a.shift : nil

Hey! Come on… Ruby’s ternary if is not mandatory… It was copied from C just as a syntax sugar. You can do without it, just as in Python:

if ! a.empty?
    v = a.shift
    v = nil

Better yet! you can use if’s return as v value:

v = if ! a.empty?

How beautiful is that!

Python lacked ternary if for a long time, and when it finally acquired one via PEP 308 its syntax was made different from every other language! Although I don’t think that is a problem, some people might think it would be better not reinventing the wheel.

Next, Kanwei goes over a famous “problem” of Ruby: the lack of a sum method for Array. I admit it’s strange, but that is completely coherent: Ruby’s Arrays are ordered collection of objects and not mathematical arrays. How do you sum objects that are not numbers? Many different people will have many different answers to that, so Ruby leaves this decision for the programmer and provides basic methods to deal with collections of anything (that can be used to apply sum to numbers, if wished). So, in Ruby you have to use Array#inject to perform a sum:

[1,2,3].inject(0) { |sum, value| sum + value }

Array#inject (actually Enumerable#inject) was borrowed from Smalltalk and allows you to loop through an array, building up an “accumulator value” as you go. When it’s done, the final value of this accumulator is returned. Very useful for combining array elements, whether by summing them, building up a pretty display string, whatever. In the example above, I am initializing the accumulator with 0.

If you use Array to mathematical operations and you want your arrays to work that way, you can always add a sum method to Array class:

class Array
    def sum
        self.inject(0) {|sum, value| sum + value}

Maybe it would be better if you just use Arrays as containers (as it was intended to) and implement that sum inside your own class… I completely agree with Reg Braithwaite here.

Kanwei also mention Python is faster than Ruby. That is true, but was “more true” some time ago. First of all, Python is older and has had more time to improve its speed. Ruby, ITOH, just now acquired a good VM and improvements to it finally can run parallel to improvements in the language itself, so I am expecting this to be less true every release. Python is already not getting much faster between releases, unlike Ruby (the differences between 1.8.7 and 1.9.1 are really impressive!). IMHO this is not a good reason to choose one instead of the other: if you really need speed, go for C 🙂

Now this is something I find interesting Kanwei has mentioned: “Python is more production ready”. He argues that Google is using it, so it must be good. Well… I cannot argue against that: Google is really using Python. But IBM, Oracle, EA, Cisco, Siemens, etc are using Ruby… so that is just a matter of preferring one or another company. Both are production ready… I agree, though, that Ruby 1.9.1 has many differences from 1.8.7, and that that may be seen as some inconsistency, but Python also has changed a lot since its 2.0 version, for that matter. And the changes to Ruby brought many benefits… I think they worth it.

At last, Kanwei compares Python and Ruby docstrings. Here I also have to agree with him: Ruby docstrings sucks. Actually that’s why everybody uses rdoc instead (and that is much more powerful than Python’s docstrings). Again, I don’t think that is reason enough to ditch Ruby (actually, the existence of rdoc, rubygems & friends should bring people to Ruby instead), but that is a matter of personal taste.

Surely, Kanwei’s reasons were easy to argue against. There are areas were Python shines much more than Ruby (and vice-versa), but those Kanwei mentioned are not among them.

I think both languages are powerful enough, and both are way better than Perl or PHP, so either one you choose would be fine. Better if you don’t have to choose and use both ;). If you have to, ITOH, pay more attention on how you feel while coding in each one, and not to some cheap reasons such as above. If you are a programmer, what matters most is that you’ll spend a lot of time coding with any given language… let that be something pleasant then.

Refresh Machine em Ruby

Posted by – 13/08/2008

Eventualmente todos enfrentaremos esta situação: você tem um objeto com “estados” que são lidos de uma fonte externa através de pooling. Usualmente você simplesmente adiciona uma thread no construtor do objeto e coloca dentro dela um loop infinito que verifica a cada intervalo de tempo se existe estado novo e, se for o caso, atualiza o estado do objeto.

Essa é uma construção muito simples e bastante utilizada, no entanto tem um problema de escalabilidade importante: para cada objeto você tem uma thread e um loop infinito. Se você tem poucos objetos, isso não chega a ser um problema… mas se tem muitos, aí é outra conversa.

Alguns vão argumentar que não é obrigatório usar essa construção, que dependendo da fonte dos dados, ela pode “atualizar” o objeto, em um padrão Observer, o que está mais do que correto… Mas nem sempre controlamos a fonte dos dados, e nem sempre ela é inteligente assim (na realizade, quando não a controlamos ela parece bantante burra!). Foi para isso que programei uma “Refresh Machine”: um container para objetos que precisam ser atualizados através de pooling. Ela presume duas coisas: que esse objeto tenha um método/atributo refresh que armazene o intervalo em segundos entre as atualizações, e um método do_refresh, que será executado entre os intervalos.

Vamos ao código:

require 'thread'
class RefreshMachine
  attr_accessor :wait
  def initialize(wait = false)
    @wait    = wait
    @killall = false
    @queue   = Queue.new
    @removed = Array.new
    @thread  = Thread.new do
      loop do
        ( @removed.clear; @queue.clear; @killall = false ) if @killall
        next if @queue.empty?
        object, last_refresh, thread = @queue.deq
        # Helps the garbage collection
        thread = nil if (! thread.nil?) and (! thread.alive?)
        # Three things can happen with a dequeued object
        if (Time.now < (last_refresh + object.refresh)) or
           (! thread.nil? and @wait)
          # First: It's too early to refresh it or we still have
          #        a refresh thread running and have to 'wait', so we
          #        just put it back in the queue
          @queue.enq [ object, last_refresh, thread ]
          if @removed.include?(object)
            # Second: We have a "remove request" for it, so we
            #         delete the request and avoid queueing it again
            # Third: It's time to refresh it, so we
            #        call do_refresh and put it back in the queue
  def add(object)
    @queue.enq [ object, Time.now, Thread.new { object.do_refresh } ]
  def del(object)
    @removed << object unless @removed.include?(object)
  def killall
    @killall = true
end # of class RefreshMachine

O objetivo é usar o mínimo possível de threads com loops infinitos…. e ficou pequena o bastante para blogar a respeito 🙂

Great News: Etch’n’Half

Posted by – 28/07/2008

Great to hear about “etch and a half”. I’ve just upgraded all my systems and everything went smooth. I dumped my home-compiled Ruby in favor of Debian’s version now, since it fixes the annoying security bug. Thanks for the good work people!

Exciting new World

Posted by – 25/06/2008

I’ve just tested the improvements in the performance of Javascript in Firefox 3 and WOW! Javascript in FF3 is really fast. While googling about it I just ran across a recent interview with Brendan Eich about the future of Javascript and I got excited about two things about this future.

First was what we already have, still in the beginning, but with a lot of potential: HotRuby. Really interesting to script a webpage in Ruby (which is my favorite language) and, while it’s not embedded the way Javascript is, it gets “compiled” in the server side with YARV (the new bytecode compiler for the next version of Ruby, 1.9), and then served to the browser in the form of JSON objects, so it can be interpreted by the Javascript engine in it. All this is transparent and work with XMLHttpRequest. It’s not a coincidence that Eich mentions it as being a form of ARAX (changing the J in AJAX for R – from Ruby).

I already do a lot of coding in Ruby… not having to deal with Javascript anymore is surely a plus. ITOH, Eich is talking about improvements in Javascript that would render it as a real programming language… Maybe coding in it would not be so painful anymore by then 😉

The whole interview have to do with this Project Tamarin, a “high-performance, open source implementation of the ECMAScript 4th edition (ES4) language specification” [ ECMAScript 4 is the same thing as Javascript 2 ] by the Mozilla developers. And this is the second thing I got excited for: they’ve planned to glue IronRuby (Ruby compiler for argh! .NET) to it via IronMonkey.

So… exciting news! Either via Tamarin or via HotRuby, we’ll get Ruby browser scripting. My “free mind” tends to favor HotRuby instead of IronRuby/IronMonkey/Tamarin… But in the end what matters is that all those people now cursed by Javascript will finally have a taste of what a real programming language feels like.. Who knows! They might even like it ;-D

Ruby security advisory and fix

Posted by – 24/06/2008

Debian 4.0 version of Ruby is open to the, now widely known, Ruby security vulnerabilities. The bug is reported as 487238 in Debian’s BTS, and is closed, since the version now in sid (version is already fixed. Users of stable can apply the patch provided by Daniel Franke (it doesn’t seem to fix all, but goes a long way).

Apparently, this brought up (again) the rants over full disclosure. Indeed, what is vulnerable is not that hard to find, as Zed Shaw showed us, so, why not talk about it in a plain and bold form? Why just provide the CVE numbers and ask for everybody to upgrade? Zed goes more deep about the quality of C code, but that is not the issue I want to talk about…

As a Free and Open Source Software supporter (and developer), I can see the benefits of full disclosure. As a not-full-time webmaster, I can see the benefits of not having a “proof-of-concept” piece of code attached to the vulnerability report. Of course, there’s a lot of things a webmaster can do to prevent having a machine completely compromised in case a security advisory is published with a proof-of-concept code in it (think about chrooting, randomized memory protection, security libraries, grsecurity, SELinux, etc) – and my machines, although vulnerable to the bug, would not be fully compromised if exploited.

I guess one should be prepared to whatever comes from the Internet… Full disclosure, in this sense, have more pros than cons, IMHO. For instance it was not clear if Debian 4.0 were vulnerable… There were no security advisory coming from Debian (and there’s still not), and it is not promptly obvious if the version packaged is affected. I know that at least I wanted to run a proof-of-concept to check if my server is vulnerable or not before going all the way into packaging a fix (or backporting the sid version), and it was not until I read Matasano Chargen Blog that I could test older versions. But different people have different ideas…