Archive for January, 2009

Ruby Ruby Ruby Ruby

January 14th, 2009

That’s it: I’m diving in.  After months of discussion (so I hear) we’re testing out a new project with that slick system, Rails.

I’ve spent the last two years developing with CakePHP (see: here).  So I feel ok with the MVC and Active Record pattern, but coding in Ruby as opposed to PHP should be interesting.  I hear it’s like a buying a shiny, modern Porche after driving around in this (too harsh? maybe).

We’re all pretty excited around here.  The Ruby project probably won’t be public, so you may want to apply for a job at the Hotel School to see what happens.  But hey, if it works out, you’ll be seeing a lot more of those popping up.  Plus: the obligatory blogging/twittering problems and their respective solutions.

First impressions, though: Rails installed awesomely via Ruby Gems.  Good sign.

Oh hai, by the way.  I’m new here.

Palm Mojo

January 12th, 2009

I thought that Palm had faded away, but they are back promoting a new phone with a new OS and SDK. According to Ars Technica , “all the software running on the device is a combination of HTML, CSS, and JavaScript.” It also uses a JSON-based message bus to communicate with the device’s various services. It sounds quite similar to the way we’ve been discussing writing our apps, with an HTML/CSS/JavaScript UI using JSON to interact with a RESTful backend web service.

SQL Trace

January 8th, 2009

PowerDNS can use a SQL database to store DNS records. I was trying to use the latest version with Oracle on the backend and it was silently failing. I wanted to know what SQL, if any it was querying with so I could track down the error. It is possible to use a listener trace to snoop for SQL, but that requires restarting the listener. You can turn on SQL tracing without bringing down the database though.

$ sqlplus sys as sysdba

...

SQL> alter system set sql_trace=true;

System altered.

... Attempt to query PowerDNS ...

SQL> alter system set sql_trace=false;

System altered.

SQL> quit

The trace files are written to /u01/app/oracle/admin/sha/udump. There are a lot of them, so it helps to list only the ones that were modified within the last day:

$ cd /u01/app/oracle/admin/sha/udump/
$ find . -mtime -1 -print
./sha_ora_28587.trc
./sha_ora_28561.trc
./sha_ora_28477.trc
./sha_ora_28515.trc
etc...
$ find . -mtime -1 -print | xargs grep record
./sha_ora_18406.trc:SELECT "domain_id", "name", "type", "ttl", "prio", "content" FROM "records" WHERE "name"='test.example.com'

As you can see it helps to have a known string in the SQL to search for. You can also use the tkprof utility to process the trace files and produce more readable output. Also, if you open a trace file in SQLDeveloper it has a nice way of presenting the data. Here is some more information on SQL trace and tkprof.