Phusion Passenger on Ubuntu 9.10

November 14th, 2009

These notes describe how to run a Rails application on a dedicated port.

Your environment will be different, so some of the following steps will be unnecessary for you and other steps may be missing.
Since we are going to build native extensions, we need to get this module:

sudo apt-get install build-essential

First, we need to install Passenger as a Apache module.

sudo apt-get install libopenssl-ruby
sudo gem install passenger
sudo apt-get install apache2-dev libapr1-dev libaprutil1-dev apache2-prefork-dev
sudo passenger-install-apache2-module

Now edit apache2.conf adding the following:

LoadModule passenger_module /usr/lib/ruby/gems/1.8/gems/passenger-2.2.5/ext/apache2/mod_passenger.so
PassengerRoot /usr/lib/ruby/gems/1.8/gems/passenger-2.2.5
PassengerRuby /usr/bin/ruby1.8

If you want to run your Rails application on a different port, add the following to ports.conf:

NameVirtualHost *:3000
Listen 3000

You need to let Apache know where the Rails application is in /etc/apache2/sites-available/default:

<VirtualHost *:3000>
  ServerName myapp.mycompany.com
  DocumentRoot /apps/myapp/public
</VirtualHost>

The last step is to restart Apache:

sudo /etc/init.d/apache2 restart

Utility functions in Flex

November 5th, 2009

I wanted to use some functions that do not belong to any visual component. I did not want to use the Java-style syntax in ActionScript (with classes and interfaces). Since ActionScript is closely related to JavaScript, I created a JavaScript-like object and put the utility functions there. The file is in src/com/mycompany/util/MYCO.as:

package com.myco.util {

	import flash.events.Event;

	public function MYCO():Object {

		this.safeNull=function(instr:String):String {
	    	return instr==null?'':instr;
	    }
}

I can reference methods in this object from other files like this:

 var blah:Function= com.myco.util.MYCO().safeNull;
 var ret:String=blah.apply(this, ['hello']);

Suppose I need access to other functions in the MYCO object, I define a locally visible variable called Myco and assign it to this:

package com.myco.util {

	import flash.events.Event;

	public function MYCO():Object {
		var Myco:Object=this;
		this.safeNull=function(instr:String):String {
                Myco.sayHelloFirst();
	    	return instr==null?'':instr;
	    },

	    this.sayHelloFirst=function():void {
	    	// saying hello
	    }
    };
}

This is because I can not just use ‘this’. ‘this’ could point to some other object, according to the rules of JavaScript.

Today

October 30th, 2009

Playing with Redis and MongoDB.

Agile versus waterfall development

November 16th, 2008

Duck typing vs. strong typing

October 16th, 2008

One year ago I wrote the original of this article after an interview. That article was lost when I reinstalled my server and did not bother to back up the database. But this time I should write better since I had time to reflect on the issue in the intervening one year.
It started when I was talking to this person who asked me whether strongly typed languages are better than duck-typed languages. That person was a manager at a company that used ActionScript. I told him both families of languages had their uses. In other cases, simply we do not have a choice. This person was shocked that I did not take sides. He had the impression that ActionScript was strongly typed (that’s what his programmers told him). He tried to convince me that strongly typed languages are better.
Compile-time checking makes sense with low-level languages, when certain statements can be checked to detect runtime problems. For example, copying from a byte array to a string (or similar) would not make sense because it would result in corruption in memory. When you go to a higher level, detection becomes harder because the compiler needs to know so much about objects at runtime. Such checks are either impossible to program or would make the compiler slow or useless.
Having no compilation errors does inspire some confidence as far as the quality of the code goes but experienced programmers know that problems occur at runtime.
Compilation of strongly-typed languages created generations of programmers who simply do not write test for their code.