Lately there has been some talking in Ruby-Talk on how to send files using scp. Some people are doing just fine by calling scp with a pre-shared password, but I don’t like that approach and it doesn’t work for my purpose, so I did a bit of experimentation and found this code works:

require 'net/ssh'
require 'net/sftp'

class SSHAgent
  def initialize
        @agent_env =
        agenthandle = IO.popen("/usr/bin/ssh-agent -s", "r")
        agenthandle.each_line do |line|
          if line.index("echo") == nil
                  line = line.slice(0..(line.index(';')-1))
                  key, value = line.chomp.split(/=/)
                  puts "Key = #{key}, Value = #{value}"
                  @agent_env[key] = value
  def [](key)
        return @agent_env[key]

agent =

Net::SSH.start( '',
              ) do |session|
                     session.sftp.connect do |sftp|
                     sftp.put_file("bigvideo.avi", "bigvideo.avi")

I was using a passwordless private key for this experiment. Should you want to use a password-protected private key, you might want to set the DISPLAY and SSH_ASKPASS environment variables or use a smartcard reader and the ‘-s reader’ parameter.

The SSHAgent class comes from a public paste (I don’t know who its author is or the license that code is under).

Lastly, there is an undesired behaviour in Net::SFTP: when you use the put_file method it loads the whole file in memory, therefore you need loads of memory if you want to send big files. I’ve tried a naive fix (iterating writes) but it didn’t work (it complains about “no such file”, I think it’s a channels-related issue). Jamis Buck, the author of Net::SFTP, told me he currently has no time to fix this issue. In case you feel brave enough, the offending method starts in line 202 in


A few weeks ago Troll Tech released official QtJava bindings under the name of Jambi. With Jambi, you can build native applications for Windows, Unix and MacOS X using Qt and Java. It’s a good idea and a good implementation, although nothing revolutionary, I myself have been successfully using QtRuby bindings for a few months.

But this mad head of mine started to think about the potential of bindings, compilers and code generation.

There are thousands of Qt developers who know the C++ API to Qt very well.

Qt is able to build native applications for many platforms (Windows, Unix and Mac OS X).

There is a number of unofficial Qt bindings (Ruby, Python, Java, Ada, Scheme, etc).

So here comes the idea: Qt-Web bindings/compiler/whatever. How could this mad idea be implemented? I have some ideas.

Keep in mind the point in the Qt-Web idea is not to have the best possible webapp development framework but to take advantage of the horde of Qt-literated people out there. Let me re-phrase that: this idea makes more sense to Troll Tech who be selling more Qt licenses and support contracts, than it makes to web developers.

As I was saying, I have several ideas on how to implement this:

  • Use Jambi to build Java applets. The return of Java applets 10 years later, wooohooo. Horrible, I know. And there is the disadvantage of downloading part of Jambi as needed or get Jambi included in the official Java repository. But that could work.
  • Qt-Flash bindings. You develop your application in ActionScript using Qt and you get a SWF. It would be more or less like the previous approach.
  • Qt-to-Flash compiler. You develop your application in C++, using the very same APIs and tools you use to develop a desktop application and you have a new “make all_flash” target that generates a SWF. 96% of computers have Macromedia Flash installed.
  • Qt-to-AJAX “compiler” (I think “translator” or “generator” would be a more appropiate word). You develop your application in C++, using the very same APIs and tools you use to develop a desktop application and you have a new “make all_ajax” target that generates HTML, CSS and Javascript. Now this has the potential to become Web 3.0: you develop webapps just like you would develop desktop apps!

After reading Penguin.swf, it looks like the reason for Adobe not to open source the Flash Player is third-party codecs (On2, Sorenson, etc).

I’d like to shoot in the air. Maybe I’ll catch a bird.

I guess Flash Player does not re-implement those codecs but uses it as an external library. Therefore, a possible solution would be:

  1. Adobe releases the Flash Player source code that belongs to Adobe, not the third-party libraries. How is this going to benefit Adobe and Flash Player in general? A lot more people would hack in the Flash Player source, improving it.
  2. Adobe defines the API to access and use these third-party libraries or even a general API for codec access. Nobody modifies those source files because if someone breaks that API, Flash would not work with third-party codecs.
  3. Flash Player may be compiled without those third-party libraries. Whenever Flash Player tries to play a Flash movie that needs codec X, it searches the local computer for the codec. If codec X is not installed, Flash Player downloads it from Adobe as a binary. Something like what the Microsoft Windows Media Player does. How is this going to benefit Adobe and Flash Player in general? Whenever Adobe decides On2 VP6 is old and wants to use On2 VP7, no new version of Flash Player is needed: just download the new codec. Using a little part of wine/darwine (just like mplayer does), this method would work in every platform.

In short, what I’m proposing is a limited-capability, full open source Flash Player and third party codecs being downloaded from Adobe as needed. After a couple of movies, everybody would have the codecs they need (unless they choose not to install them, but that’s their option).

Update There was a comment on Reddit saying wine only runs on Linux-x86 and OSX-x86. Wrong. Wine runs at least on Solaris (x86 and Sparc), Linux (x86, Sparc and PowerPC), OSX (PPC and x86) and FreeBSD (at least, x86).

Best introduction to ‘continuations’. Ever. Do not even try to understand this one.

  • Continuations are like bookmarks: "hey Joe, come here and start again from this point". The context in which you invoke the code after the continuation point is the context you are currently, not the context you had when you defined the continuation. It’s easy to see it with this code in Ruby:

    arr = [ "Freddie", "Herbie", "Ron", "Max", "Ringo" ]
    hello_var = "hello1"
    message = arr.shift
    hello_var = "hello2"
    $ unless message =~ /Max/

    The output is:

  • Closures give you the lexical context you had when you defined the closure, including values of variables.

Lately I’ve been playing with Korundum. It’s nice, it works very well and combined with KDevelop it’s a very powerful RAD.

The big problem is the lack of documentation: I’ve read Caleb Tennis’ Rapid GUI development with QtRuby and it’s a wonderful introduction, but I miss a book going deeper into QtRuby/Korundum. This is not to say it’s worthless, quite the contrary: it’s the best $8.5 I’ve spent in months.

However, the “enterprise” learning is coming from reading others’ source code (I’ve been googling for qtruby, korundum; searching Rubyforge, etc) and from Richard Dale (via #qtruby in freenode). Once again, thank you so much Richard for such a good development environment!

An interesting article I found today:

Real Programmers are reluctant to actually edit a program that is close to working. They find it much easier to just patch the binary object code directly, using a wonderful program called SUPERZAP (or its equivalent on non-IBM machines). This works so well that many working programs on IBM systems bear no relation to the original Fortran code. In many cases, the original source code is no longer available. When it comes time to fix a program like this, no manager would even think of sending anything less than a Real Programmer to do the job– no Quiche Eating structured programmer would even know where to start. This is called “job security”.

(Real Programmers Don’t Use Pascal, by Ed Post, Tektronix)

Funny how many things today we consider to be obscure and to require a master to deal with were considered toys twenty years ago.

You can identify intelligence when you see it:

I think that it’s extraordinarily important that we in computer science keep fun in computing. When it started out, it was an awful lot of fun. Of course, the paying customers got shafted every now and then, and after a while we began to take their complaints seriously. We began to feel as if we really were responsible for the successful, error-free perfect use of these machines. I don’t think we are. I think we’re responsible for stretching them, setting them off in new directions, and keeping fun in the house. I hope the field of computer science never loses its sense of fun. Above all, I hope we don’t become missionaries. Don’t feel as if you’re Bible salesmen. The world has too many of those already. What you know about computing other people will learn. Don’t feel as if the key to successful computing is only in your hands. What’s in your hands, I think and hope, is intelligence: the ability to see the machine as more than when you were first led up to it, that you can make it more.

Alan J. Perlis (April 1, 1922-February 7, 1990)

(from Structure and Interpretation of Computer Programs, MIT Press)

Update: And wait until you read the Perlis epigrams on programming. Awesome!

Everybody is talking about Novell’s decision to move from KDE and Qt to Gnome and Gtk. Me too.

My point: Novell is stupid. Plain and simple. Very stupid.

Gtk is ugly to develop with, inconsistent, lacks a lot of functionality and it is a complete joke for multi-platform development.

KDE is so superior to Gnome, the next version of Novell Desktop will be a joke. Kiosk in Gnome? No. Integration and consistency rather than a collection of non-cooperating Gtk tools? No. Lots of advanced software? No.

People say the reason behind the move from KDE to Gnome is the Qt license (pay for commercial use). What a joke. Qt is so superior to Gtk it pays for itself so soon you will never regret buying it. A Qt license is worth half the pay of one developer for one month. Your company will recover that money immediately.

Had Suse used Gtk instead of Qt, Novell would be firing twice the people they are firing now. And the movement from KDE to Gnome is so stupid they are firing theirselves on the foot.

Bye, bye, Novell, you had the best (Suse Linux, ZenWorks and eDirectory) and you decided to suicide. You can thank Miguel de Icaza, Nat Friedman and those Ximian people. This reminds me of Netscape & Collabra.