Reprise du message précédent :
Bah si t'en as jamais fait et que le projet a un planning un peu serré, ça me paraît pas forcément la panacée. Puis ce qui a fait la force de Rugy à l'origine, c'est son framework façon "j'écris le minimum de code", maintenant y'en a dans pratiquement tous les langages.

T'es sur quelle plate-forme de dev et déploiement ?
Le ruby tu peux pas trop le déployer sur du windows, c'est ultra galère à coller sur IIS (en tout cas ça l'était quand j'ai essayé).

pas serré le planning, honnêtement c'est même plus super large "en théorie" ( mais c'est vrai que c'est un beau pays la théorie, même si je ne l'ai jamais visité).
Et de quel framework tu parles ensuite? Parce qu'on rails c'est pas le seul hein!
Ce que j'apprécie dans le langage Ruby c'est le coté propre, tu peux pas mélanger un bout d'objet avec un bout de procédural à la sauce php.

ça c'est no soucaïe, server nux

Rien ne t'empêche de coder proprement en php non plus, hein.

sinon tu peux aussi regarder du côté des frameworks python genre django

oui et non...
Tout seul je suis assez d'accord mais à plusieurs ça devient vite le bordel pour uniformiser le code.
Exemple tout simple, mysql_fetch_array et mysql_fetch_assoc font la même chose ( à cause du both par défaut) alors pour ce retrouver avec le même code partout suivant le developpeur c'est toujours la merde.

sed

 
En parlant de ces deux fonctions, j'ai beau avoir lu la doc php je vois pas très bien la différence entre les deux, et j'utilise toujours le premier par habitude.

 
Hey dude, y'a des frameworks pour php maintenant
Genre CakePHP & co
FFS

Si vous appelez directement mysql_fetch_array ou mysql_fetch_assoc dans votre code y a du taff en effet  
 
Symfony a l'air bien sympa sinon : http://www.symfony-project.com/

SIERRA TANGO FOXTROT UNIFORM
  C'était un exemple ...
Mais des fonctions redondantes en php y'en à moultes, vous préférez split/explode?

 
Oui donc en gros comme vous voulez pas vous casser le cul à faire une bête norme, ni utiliser un framework existant pour vous faciliter la grosse majorité du boulot, vous préférez utiliser un nouveau langage
 
CQFD    
 
C'est le client qui va être heureux  

tiens, il a l'air pas mal lui...

+1
 
J'ai le cas en ce moment même, je bosse sur une appli pour l'intranet avec deux dev, j'ai, pour gagné du temps créé une classe abstraite qui gère tous les type de connections, relations, exécutions qu'on rencontre généralement en GDB (sous MySQL, PostgreSQL, Oracle, ect...).
 
Perso je bosse avec de l'objet parce que je préfère la syntaxe, mais je me retrouve avec des merdes dans le code, genre une instance de connexion et ensuite query écrite à la main (alors qu'il existe un $x->query())
 
Tout ça pour dire que coder à plusieurs c'est la mierda

C'est pour ça qu'il existe les claques dans la gueule

Ils ont pas eu de cours d'objet tes Roumains

Tu le fais exprès ???
95% ( et encore je suis gentil) de devs PHP codent comme des pieds pour la simple et bonne raison qu'ils ont appris/travaillé uniquement avec ce langage.
Là mise en place de norme n'est pas suffisante si elle ne s'accompagne pas d'une relecture du code (et pas qu'au début).
Et pour certains l'utilisation de framework, c'est comme confier une katana à un japanois suicidaire.
Donc le truc c'est que si on choisit php ( même avec un framework) on va se retrouver avec des inter-contrats "trop forts qui vont bien vous aider"-dixit les commerciaux et ensuite devoir recoder des morceaux entiers ( previous experience inside).
Alors si on doit former autant former sur un nouveau langage qui offre moins de possibilités dans le nawak.

Ah bah faut le dire tout de suite que vous travaillez uniquement avec des brêles
En même temps je suis pas sûr qu'en Ruby vous allez être mieux lottis

J'avais bien compris, t'inquiète
 

C'est le rôle du chef de projet de gérer ça notamment. Si tu mets plusieurs dev qui n'ont pas le niveau/autonomie de s'organiser eux-mêmes entre eux t'es obligé d'avoir un chef de projet.
 

Dans ce cas à toi de voir ce qui coute le plus cher entre : former mieux tes devs à PHP, au framework éventuellement choisi ... ou bien faire quasi le même taff de formation sur un autre langage. Faut voir les couts de maintenance également. Donc chiffrage
 

I know it's my job ...
Seuleument voilà, je préfère avoir autre chose à foutre que passer mes journées à surveiller les gens/relire du code de merde/engueuler les gens.
Avec les 2 autres devs en ce moment c'est nickel, ils sont super bons, codent proprement ( une fois qu'on s'est tous mis d'accord sur la notion de proprement et même si on relit souvent le code des autres c'est plus pour trouver des optimisations).
Mais je sais pertinement que je vais me retrouver avec 2/3 autres personnes où ça sera pas du tout le cas.

Je suis à 2000% d'accord, c'était là une grosse partie de ma question originale! Avoir des retours sur ce genre d'expérience.

Mais quoi qu'il en soit le truc qu'il faut pas oublier c'est la notion 'SS2I inside' donc en PHP:
- En plus des deux précédents devs avec lesquels je n'aurais aucun soucis, je me retrouve avec tous les inter-co ayant marqué PHP sur leur CV qui peuvent être affecté sur le projet le temps de leur retrouver une autre mission. De manière générale les fois précédentes ça a été catastrophique. Soient ils étaient bons et le temps de le "fondre dans le moule" du projet ils étaient déjà repartis. Soient... ils étaient pas bons ... du tout
En Ruby je n'aurais pas ce problème mais comme tu le soulignais la maintenance ça risque d'être coton si c'est pas nous qui nous en occupons.

Bref je me demande ...

J'ai plus le droite de taper mes collègues depuis 2002  

Le plus lourdingue, c'est que la classe à été créée pour pouvoir assurer une liaison à la base quelque soit la plateforme, et le fait de mettre des query en dur ça foire tout le portage.

Edit : Et c'est pire en css, j'en veux pour exemple ce truc ( http://tennis.gazdefrance.com/ ) qu'on a finit y'a quelques jours.
La maquette de départ était développée plus ou moins proprement, mais a finie en chaos total.

Ca me fait halluciner que ça passe la valid ( http://validator.w3.org/check?verb [...] nce.com%2F ), sachant qu'on importe des données des WYSIWYG qui date de la préhistoire avec des "<font>" a gogo, ect...

grep
 

 
C'est normal le scroll horizontal inutile sur ffox ?

 
Je l'ai pas.
Version/OS/Résolution ?
Je suis en 2.0.0.1/Windows XP/1280x1024

 
Exactly what I'm talking about   (Réglé)

Moi je l'ai
Safari / MacOS 10.4.8 / 1400*900

Plus maintenant
 
Le scroll commence à 1208px à cause de l'image de merde dans le header

+1 pour Django
 
En Python, ya Turbogears et Pylons aussi qui sont pas mal. Mais Turbogears a une doc _à chier_ (et c'est bien malheureux )

Ok retours et expérience sur Django? Temps de dev moyen vs PHP par exemple?
 
Sinon surement mais http://www.google.com/tools/firefox/browsersync/ comment ça marche trop bien
 

test

test

test

Bonjour    
 
Je cherche le code HTML pour avoir une fenetre de téléchargement qui s'ouvre quand on clique sur un lien. Une fenêtre qui propose "enregistrer sur" et "ouvrir avec" (comme on en voit beaucoup).
 
Qqun a une idée?  
 
Merki, et bonne année  

Euh, quand tu link un fichier à télécharger, une fois cliqué dessus c'est le browser qui s'occupe du reste

N'imp, le langage de template de Rails est erb, et c'est du pur Ruby, donc tu peux écrire tout et n'importe quoi dans tes templates

+1, Djangosaÿlebien

J'ai pas fait de gros trucs avec, mais

• C'est beaucoup plus propre que PHP (cause Python), donc à moyen terme beaycoup plus maintenable et rapide à développer
• Le langage  template est extrèmement simple. Ca veut dire qu'il empêche totalement tout code métier dans les templates, mais aussi que ton graphiste/htmleu pourra créer les templates tout seul comme un grand pendant que tu joueras avec le backend
• Et la simplicité du langage de templates fait que les templates sont très rapides (et cachables en intégralité ou par fragments en bonus)
• Beaucoup plus explicite que Rails depuis le magic_removal (rails a énormément de trucs qui se passent "par magie" )
• Bonnes perfs
• La génération auto d'interfaces d'admin c'est grandiose
• Django a été pensé à la base pour tourner sur PostgreSQL (si je me souviens bien)
• Le système de routes est aussi bon que celui de rails, donc on a des URLs sympas gratos

Dans les moins on a

• Son langage de template a lui, ça a des avantages mais ça veut dire un langage de templating de plus à apprendre (enfin bon il est simple)
• Son ORM, beaucoup moins puissant qu'SQLAlchemy (probablement le meilleur ORM Python). Il me semble qu' SQLAlchemy peut être pluggé mais on perd les interfaces d'admin
• Pas de migrations

Bon après si tu connais le Ruby et pas le Python faut probablement éviter Django hein

Ouais ok, ça marchait pas mais ça y est, dsl, merci!

merci, je vais donc me pencher sur python puis django voir a quoi ça ressemble/ce que ça donne.

Boah je sais pas le python c'est long à apprendre?

Être capable d'écrire un programme en Python, même d'une certaine taille, c'est pas insurmontable. C'est pas très long. La syntaxe est claire, logique...
Le faire de façon pythonique est une toute autre histoire. Le paradigme Python est assez particulier.

Apprendre à écrire du Python c'est très simple, apprendre à écrire du bon Python c'est plus dûr

Fais le Python Tutorial, puis lis Dive Into Python, ç devrait te faire une intro très correcte

C'est un problème d'idiômes pas de paradigmes

 
J'ai un problème chronique de vocabulaire sur les sujets masklinniens

si vous vous contentiez d'utiliser des mots que tout le monde comprend, aussi...

C'est pourtant simple, un idiome c'est une manière de s'exprimer propre à un groupe, donc l'idiome (ou les formes idiomatiques) d'un langage ce sont les manières normales de l'utiliser, ce sont des structures, des "phrases" plus ou moins standard du langage.
 
Un paradigme, c'est quelque chose de beaucoup plus complexe, c'est à la fois une modélisation de ce qui nous entoure et qui nous permet de l'interpréter et un ensemble de connaissances et règles communes à tous les membres d'une communauté.