Superfluo

All my solidarity to Valentina Hasan, I never understand lyrics!

(via)

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.

Two years ago I was experimenting with PostGIS on etch and in these days I'm trying to do the same with MySQL. I'm no longer maintaining a page with my system configuration because It was more annoying than useful (at least for me ;-P ), it should be enough to know that we are on a debian lenny, with MySQL 5.0.45-1.

To test the spatial extensions of MySQL, I'll use again the free GIS data about world borders. The first step is to convert the shape file in a SQL script suitable for MySQL:

• download shp2mysql from http://kartoweb.itc.nl/RIMapper/ (currently it's at version 0.4);
• compile it. Assuming that all needed library and header files are installed in the system, it's sufficient to do:

  $ gcc -lshp shp2mysql.c -o shp2mysql
  

• the usage is analogous to shp2pgsql, for example:

  $ ./shp2mysql -s 4326 ../../geo_data/world_borders/world_borders.shp world_borders db_name > world_borders.mysql.sql
  

Now you you can execute the obtained SQL script in a MySQL database and then query the world_borders table:

> select CNTRY_NAME from world_borders where Contains(ogc_geom, GeomFromText('Point(13 40)')) = 1 ;
+------------+
| CNTRY_NAME |
+------------+
| Italy      | 
+------------+
1 row in set (0.41 sec)

and that's fine.

Without the need of loading GIS data we can try some geometric functions:

> select Glength(GeomFromText('LINESTRING(12 34, 13 35)')) ;
+---------------------------------------------------+
| Glength(GeomFromText('LINESTRING(12 34, 13 35)')) |
+---------------------------------------------------+
|                                   1.4142135623731 | 
+---------------------------------------------------+
1 row in set (0.00 sec)

From MySQL 5.0 reference manual:

In MySQL, the SRID value is just an integer associated with the geometry value. All calculations are done assuming Euclidean (planar) geometry.

Does it mean that you can't do geometric calculation on spheroid with MySQL spatial extensions? I don't think so, maybe it's only a bit more complicated, read this enlighten (for me) thread: MySQL GIS

A final note: both PostgreSQL with PostGIS and MySQL spatial extensions work well under Microsoft Windows. I know it because not every coworker uses GNU/Linux, unfortunately ;-) .

Today:


For equal opportunities ;-), about 3 years ago, when I haven't a blog:

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.

A message for my 3 readers: I've just uploaded some photos.

PS: if interested subscribe to the Picasa feeds, I'm not going to inform here of updates.

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

VirtualBox is a great product and works smoothly on Lenny. Kudos!

Gabriele Renzi:

che bello, mi distraggo per un po’ e Microsoft, AOL e Digg adottano OpenID, mentre phpbb e wordpress ammiccano tramite mod e plugin.

Tim Bray:

Unless I’m missing something.

For a coincidence (I really don't remember what drove me to do it), a while ago I register to MyOpenID and so now I can identify myself as piccinini.myopenid.com and, trough delegation, as superfluo.org.
which, if no other, is pretty cool (in response to Tim Bray's What Could I Use It For Today? question ;-) ).

But I'm missing something about OpenID too and I'm going to share these doubts with my readers (have I readers??!!).

A short story: I discovered OpenID about 6 month ago while I was evaluating authentication methods for a new public web application. It immediately appeared to me as a very clever and exciting idea so I would be happy to adopt it. From another side, I wanted to follow a REST architectural style and these two requisites seemed to me very hard to conciliate and so, having already enough problems in my ToDo list, I gave up with OpenID.

Back to present, I still retain that it's a great idea but I wonder how can it be used RESTfully. Let me explain why in 4 steps:

1. to obey the RESTful principles your application should be stateless;
2. this means that you haven't a user session where to save authentication credentials;
3. this, in turn, implies that you have to authenticate every request;
4. if OpenId is part of the game, this means that for every request you have to contact an OpenId server to check the user credentials. In my opinion this is impracticable in most of the real situations.

Obviously I could be completely wrong, am I? In such case, how is it possible to use OpenID in a RESTful way? Back when I did my first evaluation I searched quickly (very very quickly, honestly speaking) but found nothing.

Joe Hewitt:

The web development paradigm wants to evolve, but we can’t build the future with yesterday’s hammer.

Tools are very important indeed.
Firebug made me love JavaScript again and preserves our relationship in the course of time ;-) .