Superfluo

Charlie:

First, if you have the choice, ditch windows, not worth it. However, if you are like me and are forced to use windows for a project then your solution is a simple derivative of what you will find here.

I'm forced to work with a Windows server too and I was experimenting the same issue. Charlie put me on the right track and I solved it adding what follows at the beginning of #{RAILS_ROOT}/config/boot.rb:

begin
  $stdout.write("checking $stdout -> ")
  $stdout.flush # really try to write!
  $stdout.write("OK\n")
rescue
  $stdout.reopen('log/mongrel.log')
  $stderr.reopen('log/mongrel_err.log')
end

As $stdout and $stderr are redirected only when IO#write raises an exception, it is effective only when Mongrel is running as a service and you still can launch it from a terminal or use a console without any problem.

I've just ported a bunch of code from dojo 0.4.x to 0.9 and I like to share some brief considerations, in the hope that they could be useful for somebody:

• most of the job consists of searching and replacing some common patterns, for example: widget declaration and creation, second argument in topic publishing method (that now is an array), etc. (see the porting guide). It's boring but easy;
• exotic usage of the dom node used in widget creation can cause problems because it seems that dojo 0.9 substitutes it with a new source dom node. In such cases a slightly refactoring is usually needed;
• what I initially missed more was the unavailability of debugAtAllCosts and dojo.hostenv.writeIncludes() but luckily the same problem (debugging evaled code) is solved in a better way by Fireclipse;
• some features are missing in dojo 0.9 but usually there is another way to achieve the same effect or one can solve the problem copying and adapting the right functions from 0.4.x.

After (to be honest) a lot of work I've completely refactored my application that consists approximatively in 15 widgets and 25 other Javascript source file (divided into two modules).

Unfortunately I can't yet precisely evaluate any performance gain because I'm having problem with the build system and the flattening of localization bundles and I'm not able to build a working release (I believe it's a bug of the build system but can't prove that ;-). Anyway:

• the (gzipped) size of the release is about 25% less than with dojo 0.4,
• rendering seems a lot faster in 0.9 respect to 0.4 (no numbers, just feelings).

In conclusion, it seems that the porting to dojo 0.9 has improved my application performance but the gain isn't so impressive. In my opinion it's better to promptly follow the evolution of the library, so I believe that it's worth to upgrade anyway.

Life is unjust and one can't always use open source technologies ;-) .

There are many guides about how to do that but they usually require to compile the drivers from source. Considering I'm using Debian lenny, I'd prefer a solution compatible with its package system, Debian has more than 18000 packages, there should be those I need! In fact it's so, first step is to install these packages:

# apt-get install tdsodbc libiodbc2 unixodbc odbcinst1debian1
[...]
#

• tdsodbcs is the package with the precompiled FreeTDS drivers,
• odbcinst1debian1 contains the utility we'll use to configure the drivers,

Second step is to inform the system that now we have the FreeTDS drivers:

# odbcinst -i -d -f /usr/share/tdsodbc/odbcinst.ini
[...]

This adds in /etc/odbcinst.ini the following section:

[FreeTDS]
Description     = TDS driver (Sybase/MS SQL)
Driver          = /usr/lib/odbc/libtdsodbc.so
Setup           = /usr/lib/odbc/libtdsS.so
CPTimeout       =
CPReuse         =
UsageCount      = 1

Third step is to configure your ODBC Data Source Names:

$ odbcinst -i -s -r
[YourDsn]
Description     = Your description
Driver          = FreeTDS
Database        = CatalogName
Server          = 192.160.1.10
Port            = 1433
odbcinst: Sections and Entries from stdin have been added to ODBC.INI
$

Note that if you execute the last command as a normal user the section is added to ~/odbc.ini.

That's all, try it:

$ isql YourDsn UID PWD
+---------------------------------------+
| Connected!                            |
|                                       |
| sql-statement                         |
| help [tablename]                      |
| quit                                  |
|                                       |
+---------------------------------------+
SQL> select * from table_name ;
[...]
SQLRowCount returns 4
4 rows fetched
SQL> 

development:
  adapter: sqlserver
  username: your_user_name
  password: your_password
  dsn: YourDsn
  mode: ODBC

It's all fine except for an annoying problem with table creation: most columns take an unspecified NOT NULL constraint and that causes a lot of troubles. Maybe somebody could suggest a remedy, it would be very well appreciated :-) .

It seems that the patch wasn't complete. In fact there was also an issue with test:acceptance task. A description of the problem and relative solution can be found here: http://forums.openqa.org/thread.jspa?threadID=5282.

Moreover, if you are wondering why you can't find any result file in selenium-on-rails/log after having run the task (as I was), the reason is that they are removed unless there are some test failures the tests take more time than a configurable limit (see selenium-on-rails/lib/selenium-on-rails/acceptance_test_runner.rb).

Did you save other 5 minutes? ;-)

2006-Dec-09 CET: modified to correct my wrong assertion about the reason why log files aren't preserved after task execution. By the way, I'd prefer if these files weren't removed when there is some failures, as I thought initially.

The problem with Selenium on Rails and Edge is described here: http://forums.openqa.org/thread.jspa?threadID=5147

You can download the patch here: http://superfluo.org/selenium-on-rails-resources/patch-for-edge-rails.20061111.txt

Nothing at all but maybe it could save 5 minutes to someone.

In this post to Streamlined group: http://groups.google.com/group/streamlined/browse_frm/thread/12444a2ec7e1c3bd/#
my recipe on how to integrate FCKeditor in Streamlined.

It uses the Ruby FCKeditor Plugin for Rails, mantained by Scott Rutherford.

I was looking again at geospatial matters when I had to reinstall PostGIS. Differently from previous time, life was easy:

stakhanov:~# apt-get install postgresql-8.1-postgis
Reading package lists... Done
Building dependency tree... Done
The following extra packages will be installed:
  libgeos-c1 libgeos2c2a postgis proj
[...]

:-D

If you are wondering why WEBrick responds to your XMLHttpRequest from Mozilla 1.7 with:
ERROR bad Request-Line `'
then read this message by prototype's author Sam Stephenson: http://lists.rubyonrails.org/pipermail/rails/2005-March/004703.html

Not surprisingly prototype includes the workaround while, unfortunately (for me), dojo doesn't.
This post in the hope that it took you less than me to discover this.

It's almost summer and it's a lot better playing volleyball under the sun than writing about technical stuffs. Anyway I've a blog and I must feed it so I'll try to add a post every one/two months. Hence, this is for June and July :-) .

The REST web-service support in Rails 1.1 is nice and powerful but how to add a new MIME type management, specifically a text/json [1] one? I haven't found any documentation about this and so I dug into the source code searching for a solution. I ended up with the following (after not few troubles):

require 'json'

# register a new Mime::Type
Mime::JSON = Mime::Type.new 'text/json', :json
Mime::LOOKUP[Mime::JSON.to_str] = Mime::JSON

# its default handler in responder
class ActionController::MimeResponds::Responder
  
  DEFAULT_BLOCKS[:json] = %q{
    Proc.new do 
      render(:action => "#{action_name}.rjson", :content_type => Mime::JSON, :layout => false) 
    end  
  }  
  
  for mime_type in %w( json )
    eval <<-EOT
      def #{mime_type}(&block)
         custom(Mime::#{mime_type.upcase}, &block)
      end
    EOT
  end
end

# its param parser
ActionController::Base.param_parsers[Mime::JSON] = Proc.new do |data|
  {:resource => JSON.parse(data)}
end

require 'json' is for the json library by Florian Frank.

Note that inserting the new Mime::Type into the LOOKUP Hash is fundamental because otherwise:

1. one can't register the param parser using the constant but has to write ActionController::Base.param_parsers[Mime::Type.lookup('text/json')] = ... ;
2. a lot more subtle, registering the param parser with this last instruction create a completely new Mime::Type object o and o.hash == Mime::JSON is false, consequently the responder isn't able to find a match!
   In fact the class Mime::Type doesn't opportunely redefine the Object#hash method though it modifies Object#eql? in order to make true o.eql? Mime::JSON. I think that this isn't appropriated: [...] must have the property that a.eql?(b) implies a.hash == b.hash [...] (from Ruby core RDoc documentation)

Now in controllers you can write something like:

  respond_to do |wants|
    wants.json 
    wants.xml
    wants.html
  end

Moreover, if your request has the right content type you'll find in param[:resource] a Ruby Hash corresponding to your JSON object.

So far, so good but I wonder if there isn't a cleaner way to do this ...

[1] actually, the official MIME type for JSON is application/json but dojo recognizes text/json. Anyway my troubles with dojo are material for another post that maybe I'll write in August ;-) .

After some plugins messed up eclipse 3.1.2, I've installed a release candidate of version 3.2 intrigued by the Callisto project. It promises to eliminate uncertainty about project version numbers and is aimed at product producers but I believe to benefit from this stability too.

The first impression is that it's faster and a lot more stable than the latest official release :-D .