Reprise du message précédent :
Vous êtes plutôt:
 
- RSpec
- Test::Unit
- autre?
- Chuck Norris n'a pas besoin de tester ses applis, alors je fais comme lui
 
Pour ma part c'était RSpec jusqu'à présent, mais je commence à me poser des questions.

Test::Unit avec une forte envie de me pencher sur shoulda

Intéressant shoulda, je ne connaissais pas.
 
J'aime particulièrement les macros pour controllers :
 

should_assign_to :user
should_respond_with :success
should_render_template :show
should_not_set_the_flash

Oui je commencais à coder un tas de helper du genre dans test_helper quand j'ai découvert ca

Tiens d'ailleurs quelques questions ;
- Vous utilisez un asset packager ? Si oui lequel (bundle-fu a l'air moins top que asset_packager meme si il nécessite un fichier de conf)
- On peut ajouter une dépendance vers une gem pour un seul environnement ?

Ha c'est cool avec Test::Unit, on n'a plus besoin de taper des_méthodes_avec_des_underscores_a_tire_la_rigaud
 
En plus je trouve qu'autospec ça embête plus qu'autre chose, du coup je ne vois plus trop d'avantage à utiliser RSpec.
 
EDIT: j'ai porté quelques specs à Test::Unit, le résultat est sans appel: RSpec ça prend 25s, avec Test::Unit ça ne prend que 15s    
 
EDIT: pendant que j'y étais j'en ai profité pour réécrire mes tests de models pour qu'ils ne touche pas à la BDD, résultat: je passe à 1.5s, ça va j'ai divisé par 10 le temps et ça teste aussi bien qu'avant  Je reconfirme que les fixtures c'est le mal.
 
- Pour l'asset packager ça doit être intéressant pour un site à fort traffic, ça permet de récupérer un peu de perfs à bas coût
- Une dépendance de gem dans un environnement, tu as testé: config.gem 'rspec' dans development.rb par exemple? Il me semble avoir testé y'a un moment mais ça marchait pas comme souhaité.

Justement on a pas accès a l'objet config dans les env/dev/prod/test/rb

C'est bizarre, parce que dans les fichiers d'environment on a des config.cache_classes = true et plein d'autres, il doit y avoir une autre subtilité.
 
Sinon la méthode crado à tester: config.gem 'pg' if RAILS_ENV = 'production'

J'ai dit n'importe quoi, j'aurais du essayer, on peut bien utiliser config dans un fichier d'environnement comme vu ici :
http://railscasts.com/episodes/156-webrat
par exemple

Au cas ou vous saviez pas quoi choisir entre nginx/thin et apache/passenger : nginx/passenger
 
http://blog.phusion.nl/2009/04/16/ [...] enger-220/

Meilleure nouvelle de la journée \o/
 
J'ai testé Passenger il y a peu, c'était le seul truc qui pouvait me faire mettre un Apache sur mon serveur de prod. Plus des questions a se poser maintenant !

Vous utilisez un plugin comme resources_controller, resource_controller, make_resourceful ou je sais pas quoi encore?
 
Avant ça ne me bottait pas, mais depuis que je me rends compte que dans ma partie admin, tous mes controlleurs se ressemblent, ça me simplifierait la vie.
 
EDIT: en même tempts ça me saoûle de déléguer toute une partie du site à un plugin qui peut ne plus être maintenu comme c'est le cas avec make_resourceful. Déjà que j'ai délégué la partie authentification à restful_auth et que je mon opinion est partagée dessus.

https://twitter.com/d2h/statuses/1590279638
 

Vous avez pas comme un petit soucis sur http://guides.rubyonrails.org/ et consorts ? Hack ?

Edit : c'est sur tout rubyonrails.org

Bloqué au taff. En substance ?

Bloqué au taff  

Merci !

Suis-je le seul à détester le camelCase, les ; à la fin d'une ligne de code et les parenthèses vides?
 
Je dis ça parce que j'avais envie de coder un peu en actionScript(); mais la syntaxe me gonfle terriblement. Ruby c'est tellement plaisant à côté.

Attends de devoir faire du PHP
 
A côté le Js (et l'actionscript dans une moindre mesure) c'est super

Ca tombe bien que t'en parle, car au moment du choix de mon langage pour le dév web, j'avais évidemment commencé avec php. Je crois que j'ai du coder pendant 2 jours maxi avant de le jeter et me tourner vers Ruby. Python était aussi en compet'    
 
Et sinon, vive l'image que donnent les développeurs durant le Golden Gate Ruby Conference! C'est bien les geeks continuez comme ça à vous la secouer devant des filles à poils  
 
D'ailleurs Mike Gunderloy a annoncé se retirer du team core rails suite aux réactions juvéniles notamment de DHH  

N'importe quoi. Il s'est retiré de sa position de Rails Activists, il a jamais fait partie de Core

Franchement, faudrait arrêter de raconter des conneries

edit:

http://twitter.com/_why/status/1640180235 _why

Oups je me suis gourré, c'est juste que je voyais beaucoup de ses commits (en tant qu'auteur) sur github, alors j'ai confondu. De là à dire que je raconte des conneries...

_why est juste génial  

Bah c'est une connerie, et facilement vérifiable. Je vois pas comment je peux dire autre chose

Vive l'externalisation de services! getexceptional n'arrive pas à se connecter à leur serveur de monitoring et Google Analytics fait ramer le chargement de mes pages  

La même chose, gentillement

Je suis en train d'écrire une nouvelle appli Rails et je vais bientôt arriver sur la partie authentification. Y'a beaucoup de buzz autour d'authlogic. Vaut-il le coup de passer du temps à le maîtriser ou bien autant rester sur restful_authentication si on le connaît déjà très bien?
 
EDIT: allé! Je tente Authlogic  
 
EDIT: crotte, il n'a pas de support pour l'activation par email, donc y'aura surement aasm à rajouter et du code  
 
EDIT: Tout le monde se plaint que restful_auth est chiant à cause de ses générateurs, mais bon là je me retrouve à faire du copy n' paste du code de son tutoriel  

Use Clearance

edit : sinon il doit bien y avoir un howto tout fait pour avoir l'activation par mail, d'ailleurs je me demande si c'est pas deja prévu dans le plugin lui-même...

En fait le côté optionnel du "email confirmation", c'est DIY.
 
Clearance c'est bien? On en entend moins parler je trouve.

C'est juste fait par les gens qui font les "meilleurs plugins du moment" (paperclip, shoulda...)
 
Et depuis peu c'est un engine donc sous rails 3 il y a extrêmement peu de code à écrire soit même

Pour les opération super longues genre encodage vidéo, etc, vous utilisez quoi:
 

• backgroundrb: lourd car chaque worker crée un process de l'appli rails! Les tâches peuvent être sauvées dans la BDD. peut gérer les tâches à la place de cron.
• workling + starling: dév par Tweeter initialement mais ne s'en servent plus? Attention lorsqu'une tâche est lue, si un plantage a lieu durant le traitement, alors la tâche est perdue. Récupérer un journal des tâches après plantage peut être très lent. Ne gère pas les tâches à-la cron.
• backgroundjob:
• spawn: je ne vois pas la différence avec un simple appel à: system ".... &"
• autre?

Resources:

• http://www.scribd.com/doc/6134982/ [...] esentation
• http://www.scribd.com/doc/2589535/ [...] s-in-Rails
• http://transfs.com/devblog/2009/04 [...] -starling/

PS: concernant Authlogic, une fois qu'on s'est tapé les méthodes esentielles à écrire soit-même, les choses deviennent agréable, et on a un User model propre et le système d'authentification reste configurable.

 
C'est rapide à faire, mais il manque un fichier a inclure dans ApplicationController pour avoir quelques méthodes de bases à propos de l'auth, comme le proposait restful_auth

Une astuce dévoilée par DHH durant Railsconf 2009:
 
Dans BaseCamp on lui avait demandé d'ajouter la possibilité d'autoriser ou de bloquer l'accès à un tâche par utilisateur. En 15 jours il a pissé un code dégueulasse. Il a alors avoué son inaptitude à réaliser cette fonctionnalité, il l'a refactoré de la manière suivante:
 
la tâche est accessible à:
- tout le monde
- une seule personne (autre que l'auteur)
- un groupe
 
Ca lui a pris 1 jour et demi à coder et tout le monde en est satisfait.
 
Du coup, j'ai remis en question mon besoin de gestionnaire de background process et je trouve que finalement system "... &" ça me convient parfaitement

Qu'est ce qui pourrait faire que dans ma console (de l'environnement de dev qui plus est), un open(mon_url) fonctionne sans problème, mais qu'il se vautre comme une grosse otarie lorsqu'il est appelé à partir d'un controller ? Ledit controller a bien le require 'open-uri'.

Edit : et question bonus, y'a un moyen simple d'exécuter ce type de requêtes longues dans un thread séparé / non-bloquant vis-à-vis du reste de la stack rails ?
Re-edit : run_later a tester.

T'as la solution backgroundrb un peu lourde certes, sinon un simple system "ma_commande et_ses_options &" lance la dîte commande dans un sous-process.

Oui, j'ai édité, c'est vrai que mon besoin n'est pas spécifique à un thread séparé mais plutôt à une exécution non-bloquante pour le reste de la requête.

Une idée pour le timeout du open ?

Edit : même chose quand la tâche est exécutée par run_later. Je précise que c'est un open sur localhost, donc je suis surpris du timeout.

Ton timeout, c'est pas une simple question de require 'open-uri'.
 
Dans la console quand tu tapes self, tu vois que tu n'es pas dans l'objet controlleur, mais un truc au-dessus dont un des attributs est ton objet controlleur. Ca me fait d'ailleurs penser que peut-être ton open(url) n'appartient pas à un controlleur mais à un model plutôt.
 
Et également je pense que le require 'open-uri' devrait plutôt se trouver dans un fichier d'initialisation de Rails plutôt que dans le fichier de définition du controlleur
 
Essaye voir.

Bon, j'ai externalisé le service avec le open dans une lib, c'est également plus cohérent. L'idée, c'est que même en faisant les manips dont tu parles (charger les require à l'initialisation du serveur), ça ne marche pas mieux.

J'ai donc une classe, dans le répertoire lib, qui se charge entre autre du open :

require 'open-uri'
  
class MaClasse
 
  def self.ma_methode(url)
    open(url)
  end
end

Je charge mon environnement de dev et MaClasse.ma_methode fonctionne comme désiré. je fais le même appel dans mon controller et là, timeout sur l'open (ma_methode est correctement appelée).

Je capte pas