While working with a multiple-database application I came across the point where I had to juggle between different environment configurations.

I had to pass connection hash to ActiveRecord::Base.establish_connection, something like this:

   1: ActiveRecord::Base.establish_connection

   2: (

   3:     :adapter  => "mysql",

   4:     :host     => "localhost",

   5:     :username => "myuser",

   6:     :password => "mypass",

   7:     :database => "somedatabase"

   8: )

This connection can be easily retrieved from ActiveRecord::Base.configurations, this is currently undocumented.

Using ActiveRecord::Base.configurations, the above can be simply written as:

   1: ActiveRecord::Base.establish_connection(ActiveRecord::Base.configurations['production'])

Akhirnya aing coba baca langsung dari situs wiki RoR, dan dapetlah alamat berikut http://wiki.rubyonrails.org/rails/pages/HowToQuicklyDoAuthenticationWithLoginGenerator eh ternyata pas dicoba  beda juga.... asem banget dah.... kenapa lagi sih...!!!

ya udahlah, mungkin Istirahat dulu aja kali yaa... dah malem gini.. mungkin besok dicoba lagi aja... :fyuh:

In typical Ruby on Rails applications you will find a lot of "AOP-like" code, especially in plugins (for example plugins for adding tags, attachments or permalinks). Plugins usually extend Rails with modules: especially the popular ActsAsSomething plugins work this way. The Plugins in Ruby on Rails are therefore also a good example of AOP. Again, Ruby on Rails shows that is has an advantage over other frameworks - it offers a very powerful ORM famework, a built-in support for testing and TDD, and easy use of AOP.

Existe una alternativa que, aunque no es puramente asíncrona, permite hacer la subida de archivos sin recargar la página de manera transparente al usuario. La idea es la siguiente:

1.- Creamos un iframe oculto de la siguiente manera:

<iframe id="upload_frame" name="upload_frame" style="display:none"></iframe>

2.- Creamos un "form_remote_tag" con "multipart"=true y target="upload_frame" así:

<% form_remote_tag (:url => { :action => :accion}, :html => {:target=>'upload_frame',:id => 'idForm' ,:multipart => true}) do%>

3.- Creamos un input type="file", llamando a una función JS onChange de la siguiente manera:

<%=file_field 'upload', 'datafile' ,:onChange=>"javascript:fileChange(this)"%>

4.- Creamos la función JS :

<script type="text/javascript">
function fileChange(upload_field){
        var re_text = /\.gif|\.jpg|\.png/i;
        var filename = upload_field.value;

        /* Comprobamos el tipo de archivo */
        if (filename.search(re_text) == -1)
        {
            alert("El archivo seleccionado no es una imagen");
            upload_field.form.reset();
            return false;

        }
/* Enviamos el formulario */
        upload_field.form.submit();
        return true;

    }
</script>

5.- Falta crear la función en el controlador que recibirá la imagen:

def accion
      name= params[:upload]['datafile'].original_filename
      directory = "public/data"
      # creamos el path
      path = File.join(directory, name)
      # escribimos el archivo con los datos recibidos en el formulario
      File.open(path, "wb") { |f| f.write(params[:upload]['datafile'].read )}
      File.delete("public/data/"+name)
end

La respuesta se enviará al iframe, pero al estar oculto no veremos ningún cambio.

NOTA: La llamada no tiene porque hacerse en el onChange del input file. Podemos crear un link a la función JS y hacer el submit de la siguiente manera:

getElementById('upload_datafile').form.submit();

Espero que os sea de ayuda!

development:
  adapter: mysql
  encoding: utf8
  database: project_development
  username: root
  password: password
  socket: /var/run/mysqld/mysqld.sock

test:
  adapter: mysql
  encoding: utf8
  database: project_test
  username: root
  password: password
  socket: /var/run/mysqld/mysqld.sock

production:
  adapter: mysql
  encoding: utf8
  database: project_production
  username: root
  password: password
  socket: /var/run/mysqld/mysqld.sock

But, RoR is strongly based on DRY (Don't Repeat Yourself) concept. And, as we can see, we have a lot of duplicated lines here.

If we pay attention, some lines of the database.yml file are repeated on development, test and production databases, and for most of the projects we have this databases on the same local. So, we have some lines repeated:

  adapter: mysql
  encoding: utf8
  username: root
  password: password
  socket: /var/run/mysqld/mysqld.sock

Googling, you can find a "DRY database.yml" scratched like this one:

login: &login
  adapter: mysql
  username: root
  password: password
  socket: /var/run/mysqld/mysqld.sock

development:
  <<: *login
  database: project_development

test:
  <<: *login
  database: project_test

production:
  <<: *login
  database: project_production

But, for me we still have some duplicated lines, and I don't like it. So here goes the "DRier database.yml":

login: &login
  adapter: mysql
  username: root
  password: password
  host: localhost

<% ["development", "test", "production"].each do |environment| %>
<%= environment %>:
  <<: *login
  database: biblemarks_<%= environment %>
<% end %>

Enjoy it!

development:
  adapter: mysql
  encoding: utf8
  database: project_development
  username: root
  password: password
  socket: /var/run/mysqld/mysqld.sock

test:
  adapter: mysql
  encoding: utf8
  database: project_test
  username: root
  password: password
  socket: /var/run/mysqld/mysqld.sock

production:
  adapter: mysql
  encoding: utf8
  database: project_production
  username: root
  password: password
  socket: /var/run/mysqld/mysqld.sock

Mas, como sempre ouvimos, um dos conceitos base do RoR é o DRY (Don't Repeat Yourself - Não repita a si mesmo). E como podemos ver neste arquivo existem diversas linhas duplicadas.

De uma forma geral as bases de dados de desenvolvimento, produção e teste residem na mesma máquina e portanto temos algumas linhas que sempre iremos repetir:

  adapter: mysql
  encoding: utf8
  username: root
  password: password
  socket: /var/run/mysqld/mysqld.sock

Googlando não é nada difícil encontrar o seguinte modelo de database.yml conhecido como "DRY database.yml":

login: &login
  adapter: mysql
  username: root
  password: password
  socket: /var/run/mysqld/mysqld.sock

development:
  <<: *login
  database: project_development

test:
  <<: *login
  database: project_test

production:
  <<: *login
  database: project_production

Mas, concordemos que ainda existe uma certa duplicação de código. Então lá vai a versão DRier do database.yml:

login: &login
  adapter: mysql
  username: root
  password: password
  host: localhost

<% ["development", "test", "production"].each do |environment| %>
<%= environment %>:
  <<: *login
  database: biblemarks_<%= environment %>
<% end %>

Update:

I am currently watching John Lam of IronRuby fame and I am totally sorry I didn't go there.

First of all, serial numbers for migrations are gone and they have made way for the UTC based names for
the migrations. So earlier (pre Rails 2.1 era) if one created migration scripts, they used to get their
names serially like...


001_create_books.rb
002_create_shelves.rb

whereas now the names have the UTC timestamps on them ...

20080601000001_create_books.rb
20080601000002_create_shelves.rb

With this new change rake db:migrate could apply all migrations that had not yet gone into database (as now
all migrations run and add an entry into the database migration table). Because of this the issue with the earlier version of migrations was taken care of i.e old migrations heavily used to rely on once single entry to run the migrations. If you somehow happened to screw the version number, u ended up getting failed migration errors.

Along came one more functionality which now lets run the up and down functions for a particular migration.

$ rake db:migrate:up VERSION=20080601000002
$ rake db:migrate:down VERSION=20080601000002

rake db:migrate:up or rake db:migrate:down let you go up or roll back a particular migration's changes.

The other change was the name of the table that stored the migration information. In earlier version of
rails, it used to be 'schema_info' which gave way to 'schema_migrations'. So I would suggest not to look
for the earlier name in case you got your application migrated from Rails 1.2.# to Rails 2.1.#.

We also got rid of specifying

t.column <attribute_name> <data_type> for the attributes and

it got reduced to

t.<data_type> <attribute_name>

which would look something like this in the new migration...

class CreateBooks < ActiveRecord::Migration
  def self.up
    create_table :books do |t|
      t.integer :code, :null => false
      t.string :name
      t.string :author_id ... for the author's sake...
      t.timestamps
    end
  end

  def self.down
    reverse the gears ...
  end
end


To add to this, timestamps came into existence which was a required addition so that we could save
some keystrokes and bid goodbye to

t.column created_at
t.column updated_at


So those were some of the changes cum additions ....
To go ahead with, lets see the cycle of migration ...

Now with the new mmigrations, when they are run, this is what happens ...

1. Table 'schema_migrations' is created if that does not exist.
2. For every migrations that runs successfully, an entry is created in the schema migrations table.
3. The leading part of the migration filename gets stored into the table.
     For eg. 20080601000001 gets saved when 20080601000001_create_books.rb runs and updates the database.
4. New migrations run when an entry is not found in the migrations table.

So now if you want to force and roll your database to a specific version, you supply the VERSION= parameter

$ rake db:migrate VERSION=20080601000002

If that version happens to be greater than those already in, the migrations will be applied. But in case the
version number is lesser than those in the migrations table, than Rails undoes the changes and self.down comes into play and thus migrations run in reverse direction to undo changes to the version that was specified.

One good thing which most of us must be missing and which is gone with arrival of the new migrations is the shorter version numbers for the migration files.

Earlier we could do something like

$ rake db:migrate VERSION=2

which has become this now

$ rake db:migrate VERSION=20080601000002

So I bet it is not so easy to remember the exact 14 character version number but I guess as long as we have Ctrl C n Ctrl V, it wont be much of a problem ;)

So to end or startup with, I think they did mature just like other things that matured with time ...
Rails included :)

Time for me to migrate to a new blog post .. till then keep migrating the new way ...

But I'm not very good at web development and this was almost my first Ruby on Rails application. Time passed, I worked a lot on Ruote-Rest, a Ruby web application based on Rack (not Rails). Ruote-rest is meant to be consumed by HTTP clients that are not browsers, you could say it's a RESTful webservice.

It is time for a second take at Ruote-Web. I started with a Rails plugin for easy integration of Ruote into a Rails application, it's simply called ruote_plugin. It provides at first migration generation (workitem storage mainly, but also engine persistence via ActiveRecord instead of the filesystem if necessary) and then helper scripts for installing the engine and its dependencies under vendor/plugins/ or as gem.

The next step was building ruote-web2 on top of the ruote_plugin. Let's note that the initial implementation of a "ruote plugin" was done by Tomaso Tosolini (who also wrote the rdbms based persistence for the process engine, Thanks a ton Tomaso !).

Ruote-web2 is way simpler than ruote-web, and it adheres to the resource structure laid by ruote-rest. It adds user and group resources though. For the user resource I didn't look very far, I used the ultra-classic restful-authentication.

This will be an interesting packaging of Ruote for people of want to "just replace the Ruote logo and place theirs" to benefit immediately from a simple and robust open source workflow engine/suite (I'm quoting someone in the community for the "just replace the logo" thing).

Ruote process definitions can be expressed as XML, Ruby and now even JSON (or YAML if you push). I plan to integrate process definition tinkering into ruote-web2 (as I did in ruote-rest) and maybe more. That should mean edition of process definitions in the process portfolio and edition of definitions of processes in-flight (already implemented in ruote-rest).

The hardest part part of this implementation work is the QA, not only the classical QA but also the QA triggered by this goal : I'd like to have the same (RESTful) interface for ruote-rest and ruote-web2. The "connectedness" aspect deserves a big share of the design (and then QA) work.

Ruote-web2 is more perhaps "ruote-rest on Rails" than "ruote-web take 2". There is a consequent amount of work left, but I'll probably be done in three or four weeks.

It's open source after all, so here are some links to the source of these tools :

http://github.com/jmettraux/ruote_plugin
http://github.com/jmettraux/ruote-web2

http://github.com/jmettraux/ruote

And finally to the mailing list :

http://groups.google.com/group/openwferu-users

1. Installation:

cmd>git clone git://github.com/mislav/will_paginate.git

2. Git Installation

You don't have git installed already then install it

Install git from here.

3. Try with this Basic Code:

a. Product model(products Table) contains these fields

id
name
price
description

b. DB has 100 records

c. controller:

def productlist
@products = Product.paginate :page => params[:page]
end

d. productlist.hml.erb

<%= will_paginate @products %>

<ul>
<% @products.each do |c| %>
<li><%= c.id %> - <%= c.name %> - <%= c.price %> - <%=
c.description %></li>
<% end %>
</ul>

Output looks Like:

Links for more help --> http://agilewebdevelopment.com/plugins/will_paginate

To display dates and datetimes in different formats in Ruby on
Rails applications, the following list for default formats
may help. The default date formats in Ruby on Rails are
:db, :time, :short, :long, :rfc822, see the Rails docs
for Time Conversions

[sourcecode language='ruby']
t = Time.now
t.iso8601      # => "2008-09-24T18:52:18+02:00"
t.httpdate     # => "Wed, 24 Sep 2008 08:52:18 GMT"
t.rfc822       # => "Wed, 24 Sep 2008 18:52:18 +0200"
t.to_s         # => "Wed 24 Sep 18:52:18 +0200 2008"
t.to_s(:db)    # => "2008-09-24 18:52:18"
t.to_s(:time)  # => "18:52:18"
t.to_s(:short) # => "24 Sep 18:52"
t.to_s(:long)  # => "September 24, 2008 18:52"
[/sourcecode]

They are defined as ..

[sourcecode language='ruby']
:db     => "%Y-%m-%d %H:%M:%S",
:time   => "%H:%M",
:short  => "%d %b %H:%M",
:long   => "%B %d, %Y %H:%M",
:rfc822 => "%a, %d %b %Y %H:%M:%S %z"
[/sourcecode]

..where the characters mean

%a - The abbreviated weekday name ("Sun")
%A - The full weekday name ("Sunday")
%b - The abbreviated month name ("Jan")
%B - The full month name ("January")
%c - The preferred local date and time representation
%d - Day of the month (01..31)
%H - Hour of the day, 24-hour clock (00..23)
%I - Hour of the day, 12-hour clock (01..12)
%j - Day of the year (001..366)
%m - Month of the year (01..12)
%M - Minute of the hour (00..59)
%p - Meridian indicator ("AM" or "PM")
%S - Second of the minute (00..60)
%U - Week number of current year, starting with first Sunday as first day of first week
%W - Week number of current year, starting with first Monday as first day of first week
%w - Day of the week (Sunday is 0, 0..6)
%x - Preferred representation for the date alone, no time
%X - Preferred representation for the time alone, no date
%y - Year without a century (00..99)
%Y - Year with century
%Z - Time zone name
%% - Literal "%" character

And you can define also your own formats using
these formats. For example,

[sourcecode language='ruby']
t = Time.now
t.strftime("Created on %m/%d/%Y") #=> "Created on 09/24/2008"
t.strftime("at %H:%M %p") #=> "at 10:52 AM"
[/sourcecode]

A number of Ruby on Rails helpers exist to assist
in formatting floating point numbers, see here

The Ruby String class has a % method to format
strings, the usage is "str % value": it uses
str as a format specification, and returns
the result of applying it to value

[sourcecode language='ruby']
"%.3f" % (1.0/7)    # "0.143"
"%5.1f" % 345.6789  # "345.7"

"%05d" % 123      # "00123"
"%-5s" % "ID"     # "ID   "
"%04x" % 0xfc14   # "fc14"

"%6.2f, %05d" % [345.6789,123]  # "345.68, 00123"
"%-5s: %04x" % ["ID", 0xfc14]   # "ID   : fc14"
[/sourcecode]

This is first time this conference was held and there were few things that were not quite as good. Some of presenters were not prepared, one of the most disappointing presentations was about RSpec and BDD by David Chelimsky . I was looking forward to this and to learn a little more about RSpec with which I am familiar but not as much as I would like to be. All started well, I learned how BDD started and... then we ran out of time ?! Then David skipped several slides and mumbled few things, let some code run on the screen and that was it. To my surprise he even got applause in the end. I guess this was more for his overall work then for this presentation. This wouldn't be so bad if this was inexperienced presenter but he doesn't seem to be.

Anyway, aside from these small imperfections, things were really nice. I enjoyed Micah Martins presentation of LimeLight, I wished he could show us more. Also one of the sponsors Mor.ph showed their service in very brief and effective presentation. In fact they convinced me to find excuse to try out their service.

Overall it was good and I am looking forward for next year. Also I will see to prepare something for next conference as I felt that there were more to Rails than what was presented, but it shows interests of the presenters.

Again thanks for preparing this conference to Chicago Ruby group.

O rails criou uma pasta chamada agenda, e colocou todas as pastas e arquivos necessários para trabalhar com o framework.

Em seguida, entrei na pasta agenda através do comando do DOS "cd agenda".

Para verificar se foi tudo criado corretamente, iniciei o servidor para testar o aplicativo. Para isso usei o comando "ruby script/server" e tive como resultado:

Depois, abri meu browser http://localhost:3000/ e o site que apareceu foi:

A partir desse momento, tudo que aparece no site é logado no console onde o server tá aberto. Volte ao console e veja o que aconteceu.

No próximo post sobre rails, já deverei ter aprendido a criar algum sisteminha em rails. Espere mais sobre a nossa agenda. Você teve o mesmo resultado ?

e aí, gostou ? então comenta, pow!

Download Ruby

Recomendo baixar a última versão.

Não esquece de habilitar o RubyGems para que possa instalar o Rails.

Para instalar o rails, precisei ir para o RubyGems, que é um gerenciador de módulos do ruby.

Mas, já com rails tive algumas dificuldades. Nas versões 1.8.6-25 e -26 o comando "gem install rails --include-dependencies" dava erro toda hora, e não foi por erro de digitação.

Consegui, nesse momento, instalar o rails apenas na versão Ruby-1.8.6-27 release candidate 1.

O resultado foi esse;

Espero que também tenha sucesso na instalação do rails em seu pc!

My initial reaction was "the rufus-scheduler has nothing to do with ActiveRecord's connection management, it's a dumb ruby library, why do you post that here ?", but I didn't word that reaction and I simply pointed at the 'connection management' issue. That paid well, since Jim came up with a solution, closing the connection at the end of each of scheduled job (ActiveRecord was implicitely opening a new connection for the job).

One of the great things with Ruby and Open Source is that you can look at the source. So I glanced at how ActiveRecord does the connection management and learnt a thing or two. (And with Ruby there is far less code to scan before reaching the objective)

The rufus-scheduler has one thread for the scheduling and then one thread for each job it triggers. One thread per job so that the scheduling thread doesn't get blocked by the job executions. In its "thread safe" mode, ActiveRecord stores its database connections in a hash whose key is the current Thread object_id. So if you have lots of job that do business with ActiveRecord, you'll have lots of threads and a[n open] connection for each of those threads.

Thanks to Jim for triggering this little active_record study and for sharing his solution.

Know thyself (and your tools).

/>
Above Unclassified Hire purchase:
/>/>/>
Beforehand@ AtomicSexKitten : Keeley Hazell's Einsteinian universe Boundary stone Separate forcibly

/>
Above Unclassified Hire purchase:
/>/>/>
Beforehand@ AtomicSexKitten : Keeley Hazell's Einsteinian universe Boundary stone Separate forcibly

/>
Above Unclassified Hire purchase:
/>/>/>
Beforehand@ AtomicSexKitten : Keeley Hazell's Einsteinian universe Boundary stone Separate forcibly

/>
Above Unclassified Hire purchase:
/>/>/>
Beforehand@ AtomicSexKitten : Keeley Hazell's Einsteinian universe Boundary stone Separate forcibly

/>
Above Unclassified Hire purchase:
/>/>/>
Beforehand@ AtomicSexKitten : Keeley Hazell's Einsteinian universe Boundary stone Separate forcibly

/>
Above Unclassified Hire purchase:
/>/>/>
Beforehand@ AtomicSexKitten : Keeley Hazell's Einsteinian universe Boundary stone Separate forcibly

/>
Above Unclassified Hire purchase:
/>/>/>
Beforehand@ AtomicSexKitten : Keeley Hazell's Einsteinian universe Boundary stone Separate forcibly

/>
Above Unclassified Hire purchase:
/>/>/>
Beforehand@ AtomicSexKitten : Keeley Hazell's Einsteinian universe Boundary stone Separate forcibly

/>
Above Unclassified Hire purchase:
/>/>/>
Beforehand@ AtomicSexKitten : Keeley Hazell's Einsteinian universe Boundary stone Separate forcibly