I’ve been doing rails development on a Vista box recently and was annoyed by how slow script/server (running mongrel) was to respond.

I am aware that Windows is slower in general for running ruby / rails but this was slooooooow.

I normally start rails development server with the standard ‘ruby script/server’ command…

C:\blah> ruby script\server
=> Booting Mongrel (use 'script/server webrick' to force WEBrick)
=> Rails application starting on http://0.0.0.0:3000
=> Call with -d to detach
=> Ctrl-C to shutdown server
** Starting Mongrel listening at 0.0.0.0:3000
** Starting Rails with development environment...
...

Notice that mongrel binds to 0.0.0.0 (as far as I remember, it used to bind to 127.0.0.1). This does work. But it is very slow, so I tried changing it to bind to 127.0.0.1

C:\blah> ruby script\server -b 127.0.0.1
=> Booting Mongrel (use 'script/server webrick' to force WEBrick)
=> Rails application starting on http://127.0.0.1:3000
=> Call with -d to detach
=> Ctrl-C to shutdown server
** Starting Mongrel listening at 127.0.0.1:3000
** Starting Rails with development environment...
...

And guess what, a subjective 300-400% increase in responsiveness. This makes the whole development process much more pleasant.

Hope this helps someone.

I’ve been using LINQ to SQL which is a very nice feature for .NET. It allows you to very quickly model your database objects as objects in code and return them as strongly typed .NET objects.

Seems to have ‘nicked’ (been inspired by?) quite a few ideas from ActiveRecord for Ruby (and Rails). In fact a lot of the new language features (e.g. predicates as anonymous functions for selection, and iterators) seem to borrow from things learnt by being exposed to dynamic languages. All in all it makes .NET much more fun to work in.

Anyway, I was using all this goodness in a project (VS.NET 2008 Orcas beta) and had all my Entities modelled and could use LINQ to query and transform my entities programmatically. I also had a few Stored procedures mapped as methods of the data context. I ran into a problem when I wanted to generate some SQL on the fly so that users could get adhoc filters of their calls.

I didn’t want to drop out into old style ADO.NET using my DBHandler as i would lose the strong typing etc. I decided to use a QueryReport table (as I’ve done numerous times before) to allow me to do ad-hoc queries without being open to SQL Injection. The table consisted of an ID, Name and SQL field. My Stored procedure could take an ID parameter, look up the SQL and use it to filter the calls table

ID           Name                SQL
1            All calls           Select * from Calls Where 1 = 1
2            Open calls          Select * from Calls Where Status = 1
3            Old calls           Select * from Calls Where TimeStamp < DateAdd(d, -14,GetDate())

ALTER PROCEDURE [dbo].[spExecStoredQuery] 
    @QueryReportID int = 0
AS
BEGIN
    SET NOCOUNT ON;
    declare @queryText varchar(500)
    select 
        @QueryText = SQL 
    from 
        QueryReports
    where
        id = @QueryReportID

    exec (@querytext)
END

The sp always returned All fields from the Calls table, so I should be able to map it to a Call object in the LINQ designer. I created the stored procedure and went about adding it as a method to the LINQ designer.

My problem occurred when I went to set it’s return value to be of type Call. It wouldn’t let me. The option was disabled and greyed out. I immediately assumed that it was because I had an Exec statement in the stored procedure, and assumed it was either a security issue or the designer could not work out it’s return type. I then removed all the exec code from sp and had it return a straight select * from calls.

This still didn’t work. I then renamed the Stored procedure to spStoredQuery. I added it to the designer and I was then able to set its Return Type to Call. This lead me to believe that the designer didn’t like the ‘exec’ in the name of the Stored Procedure. In order to test this I renamed it back to spExecStoredQuery, but, it still worked okay.

I’ve since played around with different versions and names and have discovered the following

• The first time you add the sp as a method to the designer it checks for return values to try and guess the output type.
• If it cannot guess the type, it will not let you set a return type in the designer at all
• If you delete the method then fix the stored procedure so that it returns a constant return type, the designer caches the previous type and will still not let you set a return type.
• If you rename the stored procedure and re-add it, it checks again, sees a return type (doesn’t matter what it is) This allows you to manually select a return type in the designer.
• If you then remove the non-dynamic select, and make the stored procedure dynamic, the method still works, and coerces the return type to be of type you selected.

So, the outcome of all this is: If you are dynamically generating a query in a stored procedure and want to add it as a method with a return type in the LINQ designer, add it first with non-dynamic select (select * from foo), override it’s return type if required, then add the dynamic SQL to stored procedure and you’re laughing.

I was searching online for a method to change the current working directory of a Bash session using a ruby script.

Essentially I wanted to write a shortcut script that would take me straight to the directory of whatever Rails application I was working on.

I wanted a script called ‘go’ that I could use like this:

paul@ubuntu:~$ go plopcentral
paul@ubuntu:~/Development/Sites/PlopCentral$

The script would search a few predefined base paths for the folder and then CD to that folder.

I first tried writing in pure Ruby but unfortunately, executing a ruby script that changes the current working directory within the script, loses these changes when the script exits (this is by design and completely correct, a script should not be able to affect it’s parent process)

I came up with a workaround by making the ruby script return the location of the first folder it found and used a Bash function to change to the returned folder.

Now for the script go.rb, store this in your home folder

#!/usr/bin/ruby
# searches PATHS for a folder then cds to that folder
search = ARGV[0] #get search term
PATHS = ['~/Development','~/Documents']
result = nil
PATHS.each {|path|
    result = `ls -R #{path}/ | grep -m1 -i /#{search}`.gsub!(/:$/,'') unless result
}
puts "cd #{result}" if result

This uses the OS’s ls and grep to very quickly find a path with the search term.

This on it’s own is not enough, we need the OS to take that output and use it to change the current directory. To accomplish this we need to define a function in our ~/.bashrc file.

go()
{
    eval $(~/go.rb $1)
}

This function takes it’s first parameter and passes it to the Ruby script defined before, eval’s it and uses the output (if any) to change working directory of the current Bash session.

New you can jump straight to folders with

go path

where path is a partial part the folder you want to cd to.

This is a very simple use of the method but illustrates how to use ruby with Bash and could be extended so that it uses databases etc.

Imagine Activerecord or more complex Ruby libraries for use in Bash.

Note: For those very familiar with shell programming there are bound to be pure Bash ways to accomplish this. I am more familiar with Ruby and wanted to use it.