Nouvelle étape !

[patouki]

Je suis sur Bruxelles, je peux filer un coup de main (conseils, avis...) sur la faisabilité, le découpage en modules, les estimations pour la V1...

++

Merci !
je prend contact



Et n'hésitez pas à répondre au sondage au début de la page

[Viciousity]

Rails est un framework polyvalent et un peu le précurseur de Symfony, CakePHP, etc ...

Il utilise RUBY qui a une syntaxe minimale et différente de PHP (on va pas entrer dans le débat plus lisible ou pas, cela dépend de chacun). A l'avantage d'avoir une communauté solide et son système de gem permet de gagner un temps fou en développant. De plus il est séparé maintenant en 4 couches : Models - Views - Controllers - Assets. ce qui permet de séparer clairement le travail entre dev - webdesigner (appréciable sur gros projet).
Il à l'avantage d'avoir une ligne de commande qui permet de générer automatiquement les controllers et tout ce qui va avec, des scafolds pour models,; de gérer des "tasks" (en gros des gros scripts de maintenance, backup).

Fin c'est un monde à lui tout seul qui ne cesse jamais d'évoluer et dont je ne saurai pas mentionner tous les avantages. Maintenant, il faut savoir que la communauté RUBY est surtout anglophone et moins nombreuse que pour PHP (ce qui ne veut pas pour autant dire que le langage est moins dense et comporte moins de fonctions).
Son "désavantage" c'est qu'il nécessite un serveur dédié et non mutualisé. Fin sur un projet de votre envergure, vous aurez un dédié surement donc ce n'est pas un problème.

Pour ce qui est de développer pour des plateformes mobiles, cela dépendra de votre intégrateur. C'est son boulot de créer une feuille de style différente pour navigateur mobile (iphone, BB, etc ...). Ce n'est pas super courant les développeurs mobile.
Voilà, voilà ;P

[patouki]

Rails est un framework polyvalent et un peu le précurseur de Symfony, CakePHP, etc ...

Il utilise RUBY qui a une syntaxe minimale et différente de PHP (on va pas entrer dans le débat plus lisible ou pas, cela dépend de chacun). A l'avantage d'avoir une communauté solide et son système de gem permet de gagner un temps fou en développant. De plus il est séparé maintenant en 4 couches : Models - Views - Controllers - Assets. ce qui permet de séparer clairement le travail entre dev - webdesigner (appréciable sur gros projet).
Il à l'avantage d'avoir une ligne de commande qui permet de générer automatiquement les controllers et tout ce qui va avec, des scafolds pour models,; de gérer des "tasks" (en gros des gros scripts de maintenance, backup).

Fin c'est un monde à lui tout seul qui ne cesse jamais d'évoluer et dont je ne saurai pas mentionner tous les avantages. Maintenant, il faut savoir que la communauté RUBY est surtout anglophone et moins nombreuse que pour PHP (ce qui ne veut pas pour autant dire que le langage est moins dense et comporte moins de fonctions).
Son "désavantage" c'est qu'il nécessite un serveur dédié et non mutualisé. Fin sur un projet de votre envergure, vous aurez un dédié surement donc ce n'est pas un problème.

Pour ce qui est de développer pour des plateformes mobiles, cela dépendra de votre intégrateur. C'est son boulot de créer une feuille de style différente pour navigateur mobile (iphone, BB, etc ...). Ce n'est pas super courant les développeurs mobile.
Voilà, voilà ;P

Pour les versions mobiles, je pensais passer par Jquery pour simuler un environnement propre au OS du smartphone. Les réels applications mobiles viendront beaucoup plus tard car ça demande un investissement très lourd.

exemple:
http://iphone.hohli.com/
http://m.codecomputerlove.com/flickr-uploads/

[Viciousity]

Sa reste simplement des feuilles de style alternative ^^
En gros, quand tu te connectes, ton framework détecte quelle version tu utilises en navigateur, si c'est du IOS mobile, Opera mobile, etc ... il utilise la feuille de style prédestinée au mobile, limite les actions JS non-compatible, etc ...

Pas mal de bonne inspiration : http://www.mobileawesomeness.com/

[patouki]

Sa reste simplement des feuilles de style alternative ^^
En gros, quand tu te connectes, ton framework détecte quelle version tu utilises en navigateur, si c'est du IOS mobile, Opera mobile, etc ... il utilise la feuille de style prédestinée au mobile, limite les actions JS non-compatible, etc ...

Pas mal de bonne inspiration : http://www.mobileawesomeness.com/

ok merci

et si on passe à l'application mobile propre ( pas pr tout de suite biensur) tu serais intéressé par le développement via Ruby on Rails ? ( qu'on me conseille pour les software mobile )

[niahoo]

le truc c'est que si vous faites une version en php, l'autre avec rails ça risque pas de poser des problemes de gestion de la BDD ?

[Akira777]

Ruby est tout à fait capable de travailler avec MySQL (Lien)

[Hideaki]

Je ne pense pas que nihaoo sous entendait cela, il souhait sans doute parler des accès concurrents avec la base de données et autres problèmes qui pourrait survenir si deux applications tentent de gérer la base de donnée, de surcroît il s'interrogeait sur le comportement que chaque langage gère celle-ci et non sur la capacité du langage ruby à travailler avec une base de données.

[Akira777]

Je comprend pourquoi ça me paraissait bizarre venant de niahoo xD Au temps pour moi !

M'enfin, maintenant que en parles je ne pense pas que ça pose problème. Que ce soit PHP, Java, Ruby ou autre, ils utilisent tous des drivers qui ont le même comportement et interfacent de la même manière vu que c'est normalisé... Pour MySQL, je pense qu'il ne voit même pas la différence entre ces langages.

[Viciousity]

Le seul problème pourrait venir du fait de la nommation des tables qui devra être identique pour l'accès Frameword en PHP et en RUBY. Mais je pense pas judicieux de créer une partie web en PHP et une mobile en RUBY. Autant tout centraliser sur un seul langage.

De plus créer une interface mobile peut se faire simplement grâce à une feuille de style ^^

---

2 jours de mon stage au states ont été centralisé sur la manière dont on développe des versions mobiles de sites.