RailsInstaller pour Windows

[Sephi-Chan]

Hello,

Le RailsInstaller vient de sortir ! Il s'agit d'un exécutable qui permettra à tous les Windows users (et bientôt tous les Unixiens) d'installer un environnement de développement pour Ruby on Rails en quelques clics, via un installateur classique.

En quelques minutes, vous aurez : Ruby 1.8.7, Rails 3, Git et Sqlite 3, ainsi que le DevKit (indispensable pour compiler certaines gems sur Windows).



Si vous souhaitez utiliser MySQL à la place de Sqlite, je n'ai pas de solution clé en main qui fonctionne partout. Les gens habitués à Windows (et débrouillards) qui tenteront et y parviendront pourront donner des infos.

Pour créer votre première application.

rails new my_application

cd my_application

bundle install

rake db:create

rails server

Regardez bien et prenez le temps de comprendre ce que dit votre console, ça vous évitera bien des pertes de temps !

Ensuite, http://guides.rubyonrails.org/ !

Bon Rails ! Et n'hésitez pas à poser vos questions.


Sephi-Chan

[Colmea]

Argh tu aurais dû poster quelques jours avant

J'ai installé Ruby, les gems et rails depuis la console (après avoir téléchargé Ruby évidemment) et je dois avouer que, contrairement à la dernière fois, ça c'est très bien passé (hormis le traditionnel dll de sqlite3 qui n'est jamais là sur windows).

Est-ce que l'installation de manière traditionnelle avec la console donne les même résultats qu'avec Rails Installer ?

[Sephi-Chan]

Oui, le résultat est le même. C'est aussi bien si tu as réussi à le faire à la main, ça permet de comprendre ce qui se passe.
Les paquets prêts à l'emploi sont un fléau (WAMP en tête) car ils masquent les choses au développeur. C'est mieux de savoir faire les choses.


Sephi-Chan

[niahoo]

Bon, je l'ai pas fait sur windows, j'ai kické xubuntu, installé fedora 14, installé rails via rubygems (passionnant comment rubygems pédale dans la semoule !)

Et c'est vraiment sympa cette création automatisée de CRUD, interface et routes pour chacun des types de données (enfin, là je me cantonne aux Post du tuto)

Je sais que c'est pas forcément prévu pour, mais est-il possible (et surtout, assez pratique/facile) d'utiliser rails en lui donnant autre chose qu'une DB SQL comme base de données, je pense notamment à une API REST fournie par mon serveur de jeu ?

[Sephi-Chan]

Tu peux utiliser les sources de données que tu souhaites. Un modèle n'est qu'une classe avec des méthodes.

Si tu as une interface REST, tu peux peut-être regarder du côté de ActiveResource. Tu as également l'excellente gem REST Client.


Sephi-Chan

[niahoo]

Tu peux utiliser les sources de données que tu souhaites.

Ce n'est pas aussi simple pour moi qui ne connais pas ruby, car ma classe (le modèle) Post se traduit comme ceci :

Code :

class Post < ActiveRecord::Base
end

Donc tout ce qui est CRUD est implémenté dans ActiveRecord::Base.

Pour utiliser ActiveResource, il me suffirait (~) de changer l'héritage de mon modèle ? Edit: Par contre, j'ai jamais testé, le fait de contacter sur la même machine mon serveur via le protocole http est il performant par rapport à l'ouverture d'une socket ?

désolé pour le HS

[Sephi-Chan]

Tu peux utiliser les sources de données que tu souhaites.

Ce n'est pas aussi simple pour moi qui ne connais pas ruby, car ma classe (le modèle) Post se traduit comme ceci :

Code :

class Post < ActiveRecord::Base
end

Donc tout ce qui est CRUD est implémenté dans ActiveRecord::Base.

Le langage importe peu, c'est l'idée qui est importante : étendre ActiveRecord::Base n'est qu'une façon d'ajouter des méthodes (il y a deux types de mixin en Ruby l'héritage et l'inclusion).

Tu peux tout à fait définir des méthodes qui miment le comportement de celles d'ActiveRecord. Un exemple d'un modèle à la main qui fonctionnerait avec un backend REST + JSON :

require 'json'



class User

  # Définit des attributs.

  attr_accessor :name, :email

  

  

  def self.all

    # [{"name":"Sephi-Chan","email":"sephichan@example.com"},{"name":"Niahoo","email":"niahoo@example.com"}]

    users_as_json    = RestClient.get("http://resources.example.com/users.json")

    users_attributes = JSON.load(users_as_json)

    

    users_attributes.map do |user_attributes|

      User.new(user_attributes)

    end

  end

  

  

  def self.find(id)

    # {"name":"Niahoo","email":"niahoo@example.com"}

    user_as_json = RestClient.get("http://resources.example.com/users/#{id.to_i}.json")

    

    return nil if users_as_json.code == 404

    user_attributes = JSON.load(user_as_json)

    user.new(user_attributes)

  end

  

  

  def initialize(attributes = {})

    attributes.each do |key, value|

      self.send("#{key}=", value) # Va appeller self.name=("Niahoo"), puis self.email=("niahoo@example.com").

    end

  end

  

end

Pour utiliser ActiveResource, il me suffirait (~) de changer l'héritage de mon modèle ? Edit: Par contre, j'ai jamais testé, le fait de contacter sur la même machine mon serveur via le protocole http est il performant par rapport à l'ouverture d'une socket ?

désolé pour le HS

Si ton API sait répondre aux méthodes d'ActiveRecord que tu utilises, tout devrait rouler.

Concernant les performances, je ne peux pas te répondre avec précision. Je suppose que le socket serait bien plus rapide, mais ce n'est qu'une intuition.


Sephi-Chan

[niahoo]

Hmm ok, sympa tout ça !

Juste une question de plus, pourquoi dans la classe on définit le nom des méthodes avec le mot clé self au lieu de donner simplement le nom ? (Oui je sais, j'attaque Rails avec 0 connaissance de Ruby, c'est pas très sport)

Edit : tiens bah pour le socket j'essaierai de faire une mini API également, on pourra comparer (enfin, le jour ou j'aurai commencé à coder le serveur bien sur )

[Plume]

En gros, self implique que ta méthode est une méthode d'instance, tandis que sans cette mention ta méthode est une méthode de classe.

[Sephi-Chan]

Définir self.all définit la méthode de classe.
Définir all définit la méthode d'instance.




Sephi-Chan