Philipps Blog


2012/02/12  Running a Rails 3 Application in a Sub-URI Enviroment

Filed under:Hacking,ruby,Ruby on Rails — Philipp @ 12:07 am

Sometimes you need to run your Rails (3) Application on a Sub-URI (e.g. examle.com/prod, example.com/dev). In my current Project there was a Problem with that Configuration and the Rails url-helpers (link_for, url_for, usw.) becourse the app wasn’t aware of the necessary prefix (in our example “/dev”, “/prod”).

There is always the possibility to set the apps basic URL within your app-Context. Together with setting the prefix in a System Enviroment it was possible to achieve the wanted app behaviour.
How to configure a Rails3 App with Passenger in a Sub-URI Configuration please have a look in the Phusion Passenger users guide here or in another blog post here.

The Basic Apache Configuration looks somehow like this:

<VirtualHost *:80>
    ServerName      example.com
    ServerAdmin     admin@example.com
    DocumentRoot    /var/www
    # we added two file hardlinks from our apps public folder to /var/www/dev,  /var/www/prod
        <Directory /var/www/prod>
        ...
        SetEnv RAILS_RELATIVE_URL_ROOT /prod
        ...
    </Directory>
        <Directory /var/www/dev>
        ...
        SetEnv RAILS_RELATIVE_URL_ROOT /dev
        ...
    </Directory>
</VirtualHost>

The last part is to add a Before-Hook to the ApplicationController for updating the apps default_url if RAILS_RELATIVE_URL_ROOT is set:

class ApplicationController < ActionController::Base
  protect_from_forgery

  before_filter :action_set_url_options

  def action_set_url_options
    if ENV['RAILS_RELATIVE_URL_ROOT']
      @host = request.host+":"+request.port.to_s+"/"+ENV['RAILS_RELATIVE_URL_ROOT']
    else
      @host = request.host+":"+request.port.to_s
    end
    Rails.application.routes.default_url_options = { :host => @host}
  end
end

2009/03/31  for all mac ruby devloper outs…

Filed under:Mac,ruby — Philipp @ 3:05 pm

for all mac ruby devloper outside: http://www.macruby.org any opinions about it so far?

2009/02/17  instant jruby & derby environment für eine RoR Anwendung

Filed under:Bash,Build,Java,ruby,Ruby on Rails,Tooling — Philipp @ 12:04 pm

Als angestammter Java-Entwickler geht es mir oftmals schwer von der Hand, einer Ruby on Rails (RoR) Anwendung mit relativ wenig Aufwand eine brauchbare Laufzeitumgebung zu bieten.
Normalerweise sollte das OS (MacOS 10.5.6) alles Brauchbare bieten. So ist oftmals eine Rails-Version installiert und auch das (standardmäßig genutzte) SQlite 3 ist vorhanden.
Dennoch sind es oftmals Plugins (spezielle Rails Version / spezielle gems), welche einen zusätzlichen Aufwand benötigen.
Nicht zu vergessen, dass RoR nicht auf allen Systemen vorinstalliert ist und dementsprechend ein interessierter Entwicklung von einem Out-of-the-Box Erlebnis weit entfernt ist.
Sehen wir den Tatsachen ins Auge… die Wahrscheinlichkeit eine installierte JVM vorzufinden ist (noch?) deutlich höher, als eine Lauffähige Ruby-Installation.
Was liegt also näher, als die benötigte Umgebung auf Java fußen zu lassen.
Hierzu werden verwendet:

  • jRuby in Version 1.1.5 (http://jruby.codehaus.org)
  • Derby-DB in Version 10.4.2.0 (http://db.apache.org/derby)
  • weiterhin wird eine installierte JVM (>1.5) vorrausgesetzt

 

Alles weitere wird mit Hilfe von shell-Scripten bewerkstelligt. Wobei momentan nur Unix-Scripte benutzt werden. Eine Portierung auf Windows sollte aber nur eine Sache von Minuten sein.
Es liegt eine RoR-Anwendung in einem Entwicklungs-Status vor. Diese wurde bisher in einem Netbeans-Enviroment mit einer SQlite-DB betrieben.
Das Verzeichnis ist folgendermaßen aufgebaut:

ROOT
|
|- microblog (dies ist unsere RoR-Anwendung)
|
|- derby (derby-installtion - es werden jeweils das bin und lib Verzeichnis benötigt)
| |-bin
| |-lib
|
|- jruby (jruby-installtion - es werden jeweils das bin und lib Verzeichnis benötigt)
| |-bin
| |-lib

Das Hauptproblem besteht darin, dass alle benötigten gems in das entsprechende Unterverzeichnis installiert werden müssen.
Weiterhin muss die Derby-DB mit dem entsprechenden Rake-Task auf mit der aktuellen Schema-Datei instanziiert werden.
Zuletzt sollen die vorhandenen User-Daten in die Derby-DB eingefügt werden.

  1. Anpassen der database.yml
    Wir nutzen weiterhin eine jdbc-Connection. Allerdings ändert sich der Treiber auf den der Derby-DB:
    database.yml

    development:
    adapter: jdbc
    driver: org.apache.derby.jdbc.ClientDriver
    url: jdbc:derby://localhost/microblog_development;create=true
    encoding: utf8
    pool: 5
    username: microblog
    password: microblog
    host: localhost
  2. Export der alten DB-Daten:
    Wir benutzen hierzu das Tool sqlitebrowser (http://sqlitebrowser.sourceforge.net) und erzeugen uns so einen SQL-Dump der alten SQLite-DB. Wir benutzen hierbei nur die SQL-Inserts für den User-Import. Diese speichern wir in die Datei:
    microblog/db/microblog.sql
  3. Für den Import erstellen wir einen Rake-Task:
    microblog/lib/tasks/sql-import.rake

    namespace :microblog do
    desc 'Import old SQL Data'
    task :sqlimport => :environment do
    dbConn = ActiveRecord::Base.establish_connection :development
    sql = File.open("db/microblog.sql").read
    sql.split(';').each do |sql_statement|
    dbConn.connection.execute(sql_statement)
    end
    puts "imported user data '#{Time.now}' "
    end
    end
  4. Erstellen des Setup-Scriptes:
    Folgende Schritte sind notwendig:

    1. Setzen aller benötiger Verzeichnisse
    2. installieren aller benötigter gems
    3. Starten des Derby-DB-Servers
    4. Rake db:migrate
    5. import der alten Daten
    6. Beenden des Derby-DB-Servers

    Das Script sieht wie folgt aus:
    jruby-setup.sh

    #!/bin/sh
    BASE_DIR=`pwd`
    CP=".:$BASE_DIR/jruby/lib/*:$BASE_DIR/derby/lib/derbyclient.jar"
    JAVA_OPTS="-Djdbc.drivers=org.apache.derby.jdbc.EmbeddedDriver"
    JRUBY="$BASE_DIR/jruby/bin/jruby"
    DERBY_HOME=`cd derby && pwd`
    export DERBY_HOME=$DERBY_HOME
    cd $BASE_DIR
    echo "setting up jgems..."
    $BASE_DIR/jruby/bin/jruby $BASE_DIR/jruby/bin/jgem update --system
    $BASE_DIR/jruby/bin/jruby $BASE_DIR/jruby/bin/jgem install jruby-openssl --no-rdoc --no-ri
    $BASE_DIR/jruby/bin/jruby $BASE_DIR/jruby/bin/jgem install -v=2.2.2 rails --no-rdoc --no-ri
    $BASE_DIR/jruby/bin/jruby $BASE_DIR/jruby/bin/jgem install activerecord-jdbc-adapter activerecord-jdbcderby-adapter --no-rdoc --no-ri
    echo "starting derby..."
    $BASE_DIR/derby/bin/startNetworkServer &
    echo "setting up derby..."
    cd microblog
    $BASE_DIR/jruby/bin/jruby $BASE_DIR/jruby/bin/rake db:migrate
    $BASE_DIR/jruby/bin/jruby $BASE_DIR/jruby/bin/rake microblog:sqlimport
    cd $BASE_DIR
    echo "stopping derby..."
    $BASE_DIR/derby/bin/stopNetworkServer &

    Es ist zu erwähnen, dass es notwendig ist, jeweils auf die entsprechende jRuby-Installation zu verweisen.
    Weiterhin benötigt jRuby den entsprechenden derbyClientDriver, welcher in die (von jRuby später verwendete) JAVA_OPTS-Variabel eingetragen wird.
    Ebenfalls musst der Classpath soweit angepasst werden, dass sowohl jRuby, als auch Derby über die notwendigen Bibliotheken verfügen.
    Als letztes ist noch erwähnenswert, dass die beiden Rake-Tasks jeweils aus dem App-Verzeichnis ausgeführt werden.

  5. Das Start-Script.
    Letzendlich sind auch zum eigentlichen Betrieb des Servers Anpassungen notwendig, da auch hier die jRuby-Instanz mit den verwendeten gems benutzt werden sollen.
    Das Script sieht wie folgt aus:
    run.sh

    #!/bin/sh
    BASE_DIR=`pwd`
    CP=".:$BASE_DIR/jruby/lib/*:$BASE_DIR/derby/lib/derbyclient.jar"
    JAVA_OPTS="-Djdbc.drivers=org.apache.derby.jdbc.EmbeddedDriver"
    JRUBY="$BASE_DIR/jruby/bin/jruby"
    export BASE_DIR=$BASE_DIR
    export JRUBY=$JRUBY
    DERBY_HOME=`cd derby && pwd`
    export DERBY_HOME=$DERBY_HOME
    cd $BASE_DIR
    echo "starting derby..."
    $BASE_DIR/derby/bin/startNetworkServer &
    echo "setting up derby..."
    cd microblog
    $BASE_DIR/jruby/bin/jruby $BASE_DIR/jruby/bin/rake db:migrate
    echo "starting microblog"
    $BASE_DIR/jruby/bin/jruby $BASE_DIR/microblog/script/server
    echo "stopping derby..."
    $BASE_DIR/derby/bin/stopNetworkServer &

    Es entspricht also einer abgespeckten Variante des Setup-Scriptes. Hierbei wird auch immer ein db:migrate aufgerufen, für den Fall, dass sich die DB-Struktur in der Zwischenzeit geändert haben sollte.

  6. Auslieferung ;-).
    Derby und jRuby belegen knapp 80 MB sodass es notwendig ist, die Dateigröße für den Transport zu verringern.
    Zuallererst sollten die benötigten gems am besten immer online bezogen werden, sodass man hier ein paar MB sparen kann.
    Weiterhin benutzen wir Jar um die vorhandenen Dateien auf ein 13 MB-Archiv zu packen.
    Die veränderten Scripte sehen wie folgt aus:
    Zuerst das Script, welches die vorhandenen Dateien packt:
    pack.sh

    #!/bin/sh
    find . -name '*.DS_Store' -type f -delete
    jar -cvf statusQ-runtime.jar derby/ jruby/ run.sh pack.sh microblog/db/microblog.sql microblog/lib/tasks/sql-import.rake
    rm -R jruby
    rm -R derby
    rm run.sh
    rm microblog/db/microblog.sql
    rm microblog/lib/tasks/sql-import.rake
    rm pack.sh

    Und nun das geänderte jruby-setup.sh Script, welches vor dem eigentlichen Setup noch für das Entpacken aller Dateien verantwortlich ist:
    jruby-setup.sh

    #!/bin/sh
    jar -xvf statusQ-runtime.jar
    rm -R META-INF
    chmod +x run.sh
    chmod +x setup.sh
    chmod +x pack.sh
    chmod +x jruby/bin/jruby
    chmod +x derby/bin/startNetworkServer
    chmod +x derby/bin/stopNetworkServer
    BASE_DIR=`pwd`
    CP=".:$BASE_DIR/jruby/lib/*:$BASE_DIR/derby/lib/derbyclient.jar"
    JAVA_OPTS="-Djdbc.drivers=org.apache.derby.jdbc.EmbeddedDriver"
    JRUBY="$BASE_DIR/jruby/bin/jruby"
    DERBY_HOME=`cd derby && pwd`
    export DERBY_HOME=$DERBY_HOME
    cd $BASE_DIR
    echo "setting up jgems..."
    $BASE_DIR/jruby/bin/jruby $BASE_DIR/jruby/bin/jgem update --system
    $BASE_DIR/jruby/bin/jruby $BASE_DIR/jruby/bin/jgem install jruby-openssl --no-rdoc --no-ri
    $BASE_DIR/jruby/bin/jruby $BASE_DIR/jruby/bin/jgem install -v=2.2.2 rails --no-rdoc --no-ri
    $BASE_DIR/jruby/bin/jruby $BASE_DIR/jruby/bin/jgem install activerecord-jdbc-adapter activerecord-jdbcderby-adapter --no-rdoc --no-ri
    echo "starting derby..."
    $BASE_DIR/derby/bin/startNetworkServer &
    echo "setting up derby..."
    cd microblog
    $BASE_DIR/jruby/bin/jruby $BASE_DIR/jruby/bin/rake db:migrate
    $BASE_DIR/jruby/bin/jruby $BASE_DIR/jruby/bin/rake microblog:sqlimport
    cd $BASE_DIR
    echo "stopping derby..."
    $BASE_DIR/derby/bin/stopNetworkServer &

Als nächstes sollte die Scripte auf Windows portiert werden.
Weiterhin wäre es interessant, die Derby/jRuby Binaries jeweils direkt online zu beziehen.

2008/07/05  my very first (ehm… useful ?!?!) ruby script.

Filed under:NAS,nexenta,ruby — Philipp @ 1:07 am

So concerning my first try of a web based zfs managment interface i will restart the project with some new conditions:

  • 1. i will switch from the former language PHP to the – like everywhere told – dev-friendly language ruby.
  • 2. i will first concentrate on just the basic functions.
  • 3. i have to use the system build in security realms (so either PAM or an equal interface)
  • 4. i will use dynamic JS-Functions to enhance the GUI. But the system should also work with simple browser (e.g. lynx/links)
  • 5. i will offer a RESTful interface. So it should be very easy for 3rd party apps to connect to them and use alle the functionality.

The Beginning ^^:
So my first task is to bring an overview of all system-disks (other devices are not necessary at the moment) into my ruby context.
So basic system command is:

root@sunny:~# format < /dev/null
Searching for disks…

The device does not support mode page 3 or page 4,
or the reported geometry info is invalid.
WARNING: Disk geometry is based on capacity data.

The current rpm value 0 is invalid, adjusting it to 3600
done

c3t0d0: configured with capacity of 18.61GB

AVAILABLE DISK SELECTIONS:
0. c0d0 <DEFAULT cyl 3734 alt 2 hd 255 sec 63>
/pci@0,0/pci-ide@11,1/ide@0/cmdk@0,0
1. c3t0d0 <ST92011A–3.04 cyl 2430 alt 2 hd 255 sec 63>
/pci@0,0/pci925,1234@11,3/storage@2/disk@0,0
Specify disk (enter its number):

Beside of the interesting warning, this will do the job. The format command will normally lead to a prompt. To avoid this, you just pipe the output to /dev/null.

The really valuable stuff is in the upper part of the output.
After consulting the ruby API about strings and arrays i ended up with the following (dirty) lines of code:


#!ruby
#!/usr/local/bin/ruby -rubygems

s = %x{format < /dev/null}
sa = s.split(“\n”)
counter = 0
dsk = false
puts “Array: “+sa.length().to_s()
sa.map do |i|
if i.strip().length() > 0
print counter.to_s()+” ”
if counter == (sa.length()-1)
dsk = false
end
if dsk == true
puts “DSK: “+i.strip()+”\n”
else
puts i.strip()+”\n”
end
if i.eql?(“AVAILABLE DISK SELECTIONS:”)
dsk = true
end

end
counter += 1
end

I found a really nice post about the ruby command line interface. That post gave me a good start in experimenting with the produced string output. You just always remember the irb to test parts of your code. Of course there is _A_Lot_ of debugging code. But the end-result is correct. Of course there should no hard-coded string in there. A by the way: it was a little bit inconvenient to quarrel again with the integer<->string conversion after some relaxing and luxurious years coding Java ^^. Okay so no implicit casting in ruby (?). Oh wait a minute – no typed language, so no casting?.

Oh yes… i don’t want to hide the output:

root@sunny:~$ ruby cmd.rb

The device does not support mode page 3 or page 4,
or the reported geometry info is invalid.
WARNING: Disk geometry is based on capacity data.

The current rpm value 0 is invalid, adjusting it to 3600
Array: 12
0 Searching for disks…
1 done
3 c3t0d0: configured with capacity of 18.61GB
6 AVAILABLE DISK SELECTIONS:
7 DSK: 0. c0d0 <DEFAULT cyl 3734 alt 2 hd 255 sec 63>
8 DSK: /pci@0,0/pci-ide@11,1/ide@0/cmdk@0,0
9 DSK: 1. c3t0d0 <ST92011A–3.04 cyl 2430 alt 2 hd 255 sec 63>
10 DSK: /pci@0,0/pci925,1234@11,3/storage@2/disk@0,0
11 Specify disk (enter its number):


So i guess i found my disks. At the end, i can just iterate about the even number of entries :-).
Okay ruby-gurus. How can i optimize my code. I am beginner level and “slurred” during years, coding Java and anciently PHP.
I am sure there is a lot of potential to cleanup this mess ^^.

Blogged with the Flock Browser

2008/07/04  very first test with ruby camping :-)

Filed under:nexenta,ruby,Tech — Philipp @ 11:35 pm


I tried The Camping Short, Short Example for the ruby camping framework.

#!ruby
 #!/usr/local/bin/ruby -rubygems
 require 'camping'

 Camping.goes :HomePage

 module HomePage::Controllers

   # The root slash shows the `index' view.
   class Index < R '/'
     def get
       render :index
     end
   end

   # Any other page name gets sent to the view
   # of the same name.
   #
   #   /index -> Views#index
   #   /sample -> Views#sample
   #
   class Page < R '/(\w+)'
     def get(page_name)
       render page_name
     end
   end

 end

 module HomePage::Views

   # If you have a `layout' method like this, it
   # will wrap the HTML in the other methods.  The
   # `self << yield' is where the HTML is inserted.
   def layout
     html do
       title { 'My HomePage' }
       body { self << yield }
     end
   end

   # The `index' view.  Inside your views, you express
   # the HTML in Ruby.  See http://code.whytheluckystiff.net/markaby/.
   def index
     p 'Hi my name is Charles.'
     p 'Here are some links:'
     ul do
      li { a 'Google', :href => 'http://google.com' }
      li { a 'A sample page', :href => '/sample' }
     end
   end

   # The `sample' view.
   def sample
     p 'A sample page'
   end
 end


It seems to be very easy to create the separat pages.

The example above generates one entry page. (the index method in Views) and one additional page (sample method).
As far as i should know it from rails, it uses the same MVC pattern and theres is a similar syntax. Just the Views are in native ruby without mixing up with html.
But maybe that will appear later on.
The next step is to see howto connect ruby with some inner sys-functions of nexenta ^^.

Blogged with the Flock Browser

2008/07/03  Installing ruby camping

Filed under:nexenta,ruby,Tech — Philipp @ 10:08 pm


Just a short one:

After succeeding in installing ruby gems, i finally was able to install the ruby micro-framework camping.
So ruby should just be used as a small administration web interface. In my eyes a rails aproach seems to be like breaking a fly on the wheel.

Just easy as this:

  root@sunny:~# gem install camping –source http://code.whytheluckystiff.net
    …
    Installing ri documentation for markaby-0.5…
    Installing ri documentation for camping-1.5.180…
    Installing RDoc documentation for activesupport-1.4.2…
    Installing RDoc documentation for builder-2.1.1…
    Installing RDoc documentation for markaby-0.5…
    Installing RDoc documentation for camping-1.5.180…

Smooth and easy. Ready to rumble ;-).

Blogged with the Flock Browser

  Install Gems (Ruby with zlib) on Nexenta (GnuSolaris) 1.01

Filed under:nexenta,ruby,Tech — Philipp @ 9:59 pm

Next in the row is the installation of the ruby gems package.
So it should be easy… just following the instructions.
So…..

root@sunny:~# wget http://rubyforge.org/frs/download.php/38647/rubygems-1.2.0.zip
root@sunny:~# unzip rubygems-1.2.0.zip
root@sunny:~# cd rubygems-1.2.0
root@sunny:~# ruby setup.rb config
./lib/rubygems/spec_fetcher.rb:1:in `require': no such file to load — zlib (LoadError)
from ./lib/rubygems/spec_fetcher.rb:1
from ./lib/rubygems/source_index.rb:10:in `require’
from ./lib/rubygems/source_index.rb:10
from ./lib/rubygems.rb:767:in `require’
from ./lib/rubygems.rb:767
from setup.rb:22:in `require’
from setup.rb:22

Welcom to error world ;-).
Okay…. should be easy to solve:

root@sunny:~# apt-get install libzlib-ruby zlib1g-dev

or for 64bit Plattforms:

root@sunny:~# apt-get install libzlib-ruby lib64z1-dev

But still the same Error!
Finally i found something in the Weblog of Lucas Chan.
Hm its about readhat/centos…. okay why not.
Just go to the ruby sources:

root@sunny:~# cd /usr/local/src/ruby-1.8.6-p110/
root@sunny:~# cd ext/zlib
root@sunny:~# ruby ruby extconf.rb –with-zlib-include=/usr/include –with-zlib-lib=/usr/lib
checking for deflateReset() in -lz… yes
checking for zlib.h… yes
checking for kind of operating system… Unix
creating Makefile

root@sunny:~# make
root@sunny:~# make install

and finally:

root@sunny:~# cd /usr/local/src/rubygems-1.2.0/
root@sunny:~# ruby setup.rb config
….
== Thanks

Keep those gems coming!

— Jim & Chad & Eric (for the RubyGems team)

Again: something learned!

Blogged with the Flock Browser

2008/07/01  Install Ruby on Nexenta (GnuSolaris) 1.01

Filed under:nexenta,ruby,Tech — Philipp @ 1:44 am

If you want to build your own small ruby script for administrating you Nexenta-Box, you normally just have to do a:

root@sunny:~# apt-get install ruby

Unfortunetally this Package seems to be broken:

root@sunny:~# ruby -v
ld.so.1: ruby1.8: fatal: libruby1.8.so.1: open failed: No such file or directory

The needed lib libruby1.8.so.1 is not on its desired place.
So you need to compile yourself a version of ruby:


root@sunny:~# apt-get remove ruby
root@sunny:~# apt-get autoremove
root@sunny:~# apt-get install build-essential

root@sunny:~# cd /tmp
root@sunny:~# wget ftp://ftp.ruby-lang.org/pub/ruby/1.8/ruby-1.8.6-p110.tar.gz

root@sunny:~# tar xvfz ruby-1.8.6-p110.tar.gz
root@sunny:~# cd ruby-1.8.6-p110

root@sunny:~# ./configure
root@sunny:~# make
root@sunny:~# make test-all
root@sunny:~# make install
root@sunny:~# make install-doc

/usr/local/bin should be in your path!

root@sunny:~# echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11

root@sunny:~# make install-doc


root@sunny:~# which ruby
/usr/local/bin/ruby
root@sunny:~# ruby -v
ruby 1.8.6 (2007-09-23 patchlevel 110) [i386-solaris2.11]

DONE!

Blogged with the Flock Browser