Choisir des outils de développement Mac

[Bernard Senior]

pas de soucis.
et si tu vas sur http://www.php.net/manual/fr/ et sur http://www.nexen.net/docs/php/annotee/tu trouveras de la documentation en ligne de php en francais et quelque trucs à ne pas faire(ou à faire. )

Merci pour ces nouveaux tuyaux. J'ai commencé le tutoriel de phpdebutant. C'est au poil ! Exactement ce que je cherchais pour débuter. J'ai aussi téléchargé la doc de php en format chm. Impeccable pour la consultation !

 

[Macbasse]

Merci pour ces nouveaux tuyaux. J'ai commencé le tutoriel de phpdebutant. C'est au poil ! Exactement ce que je cherchais pour débuter. J'ai aussi téléchargé la doc de php en format chm. Impeccable pour la consultation !

Salut !

Puisque je vois que tu sembles glisser vers une solution "Web" pour créer une application, as-tu jeté un oeil du côté du framework Ruby on Rails (http://www.rubyonrails.org/) ?
J'imagine que l'idée de pouvoir s'appuyer sur un outil plus avancé pour créer des interfaces n'est pas négligeable dans le projet que tu as.
Personnellement c'est ce qui me fait traîner les pieds dans l'idée d'utiliser PHP/MySQL. RoR mise sur AJAX qui est visiblement fort prometteur en ce qui concerne les possibilités qu'il laisse pour les interfaces.

Il y a par exemple un bouquin sympa sur le sujet :

http://www.eyrolles.com/Informatique/Livre/9782212117462/livre-ruby-on-rails.php

Reste qu'il faut se taper un nouveau langage et que je ne connais pas la courbe de progression d'un novice en Ruby.

Quelqu'un a-t-il du recul là-desus ?

A+

 

[Bernard Senior]

Salut !
Puisque je vois que tu sembles glisser vers une solution "Web" pour créer une application, as-tu jeté un oeil du côté du framework Ruby on Rails (http://www.rubyonrails.org/) ?

Merci de ton avis. Décidément, ce fil lancé voici plus d'un mois, n'en finit pas de rebondir grâce à vos multiples contributions. Cela semble prouver que nous y abordons ensemble des thèmes qui sont au coeur des préoccupations de beaucoup.

J'ai pris le temps hier après-midi d'examiner ta suggestion. J'ai même téléchargé le tutoriel Ruby de Projectomega.org. Il s'avère que Ruby est un langage de POO pur et dur, puisque "tout est objet" (cf. tuto. par ailleurs très pédagogique). Pour moi, qui vient d'une longue pratique de la programmation procédurale, cela constitue un obstacle supplémentaire. En effet, c'est déjà lourd de changer de langage de programmation mais si en plus on plonge sans transition dans la POO, la marche peut s'avérer trop haute, à moins d'être un petit génie ! PHP présente pour moi l'avantage de permettre les deux approches de programmation. Je sais que les puristes considèrent que c'est un peu bancal. Certes ! Mais je ne vise pas impérativement la programmation concise, élégante et tout et tout... Je cherche avant tout l'efficacité et une certaine pérennité. PHP doit bien avoir quelques qualités notables pour être devenu si rapidement un must sur le web et sa très forte implantation augure bien de l'avenir.

Quand à Ruby on Rails, je suppose que l'utilisation de ce framework (charpente, bâti, cadre, squelette...au choix) impose d'avoir bien assimilé la programmation en Ruby, afin de pouvoir y implanter et développer son propre code.

A+

 

[SuperCed]

Je cherche avant tout l'efficacité et une certaine pérennité. PHP doit bien avoir quelques qualités notables pour être devenu si rapidement un must sur le web et sa très forte implantation augure bien de l'avenir.

C'est indéniable. Autant pour faire de la programmation d'applicatifs, il reste toujours des débats entre celui qui va utiliser du Java, ou alors du C, ou encore du C++, ou encore Python, etc. Autant pour le web, c'est très clair. S'il n'y a pas un gros bloc métier en Java déjà présent, c'est php qui est loin devant. pour le web, sa suprématie n'est plus à démontrer.

 

[Tarul]

c'est vrai, j'avais oublié ruby. j'avais un peu maté le tutoriel video. c'est quand même impréssionnant. mais contrairement à php, il n'y a pas beaucoups d'herbergeur à ma connaissance qui le propose.

pour le developement ne objet, c'est pas si dur que cela semble être. le tout est de trouver des bon tuto lorsqu'on ne peut pas être en cours de dev(comme moi ^^, licence info powa ). sinon comme ressource supplémentaire il y a http://www.developpez.com/ et [URL="http://www.codes-sources.com"]http://www.codes-sources.com. Sinon il y a aussi [URL="http://phpfrance.com"]http://phpfrance.com, et enfin [URL="http://asp-php.net"]http://asp-php.net
Si les deux premiers sont généraliste, ils disposent de bon tutoriels en tout genre, des codes sources, des FAQ complète et un forum dynamique. les deux derniers sont plus orienté php, avec des explications de comment faire certaines chose(comme un uploadeur de fichier).[/URL]
[/URL]
Je dirais qu'au final l'idéal est de choisir le langage qui te plait le plus, qui sera rapproche le plus a ton objectif, et le plus répandu(dans le cas d'une utilisation sur un serveur web).[/URL]

Je terminrais par dire, je te déconseilles fortement le java pour faire des pages web ou des servlets(comme on dit). c'est peut être puissant, mais faut s'y mettre pour faire ce que l'on veut.(en plus d'apprendre l'objet, le java, il te faudra apprendre l'api correspondant au servlets, et l'utilisation du serveur tomcat qui gère les servlet). On a commencé à en faire en cours, et j'ai beaucoups de mal(faudrais peut être que j'y passe plus de temps dessus aussi ).
[URL="http://www.codes-sources.com"][URL="http://phpfrance.com"][/URL][/URL]

 

[Bernard Senior]

Pour le developement ne objet, c'est pas si dur que cela semble être. le tout est de trouver des bon tuto lorsqu'on ne peut pas être en cours de dev(comme moi ^^, licence info powa ). sinon comme ressource supplémentaire il y a http://www.developpez.com/ et [URL="http://www.codes-sources.com"]http://www.codes-sources.com. Sinon il y a aussi [URL="http://phpfrance.com"]http://phpfrance.com, et enfin [URL="http://asp-php.net"]http://asp-php.net

Merci de tes tuyaux. J'avais déjà repéré phpfrance.com. C'est vrai que le développement orienté objet n'est peut-être pas si difficile. Mais bon... J'ai regardé un peu sous le capot de Dolibarr, une application web libre. Cela fait quand même un peu peur... Il faut s'accrocher ! Enfin, on verra.

 

[OlivierL]

C'est vrai que le développement orienté objet n'est peut-être pas si difficile

C'est pas si difficile, mais c'est surtout très facile de faire n'importe quoi et même pire
Si on passe aux technos objets, il faut avoir conscience de ce que ca veut dire. Si c'est pour faire du spaghetti en Java, alors là c'est la cata !

 

[Bernard Senior]

C'est vrai que le développement orienté objet n'est peut-être pas si difficile
C'est pas si difficile, mais c'est surtout très facile de faire n'importe quoi et même pire
Si on passe aux technos objets, il faut avoir conscience de ce que ca veut dire. Si c'est pour faire du spaghetti en Java, alors là c'est la cata !

Qu'est-ce tu veux dire par là ? Je ne vois pas trop ce que peut être de la prog. en spaghetti ! Peux-tu m'éclairer là-dessus ? Si je me lance dans l'objet, j'aimerais démarrer sur de bonnes bases. La difficulté pour moi, c'est d'arriver concrètement à transformer du code procédural en code orienté objet. J'ai regardé quelques tutoriels simples sur les classes en PHP. Cela reste un peu théorique. Je ne vois pas trop comment appliquer cela à mes propres lignes de code.
Je me demande également si je fais bien de vouloir reprendre et adapter une application web existante. Cela suppose que je comprennes parfaitement la structure du code. De plus, Dolibarr est une appli. PHP4. Or, d'après ce que j'ai compris, le changement entre PHP4 et PHP5 porte surtout sur le modèle objet. Comme Dolibarr est entièrement programmée en objet, il me semble que ce serait préférable de me lancer directement en PHP5.

 

[GrandGibus]

[ce n'est que mon avis]

Pour ma part, je commencerai par analyser mes besoins et essayer de séparer le fonctionnel: les actions à mener du structurel: les structures qui véhicules les données. En cela, l'application existante pourra s'avérer très utile, puisqu'il s'agit d'un portage.

De plus, autant il est bien de s'inspirer de code existant: genre telle fonction comment ont-ils pu faire ?... Mais cela peut s'avérer aussi dangereux: Pour tordre un cadre existant, il faut bien avoir conscience des risques et des limites, sous peine de voire ce cadre tenir guère longtemps et se retrouver prisonnier d'un carcan (image du cadre ).

Donc, pour résumer, je mets d'un coté tout ce dont j'ai besoin:

• identifier les acteurs (qui)
• identifier les services rendus (fait quoi)
• identifier les structures qui vont véhiculer les données pour ces mêmes services (avec quoi)

A cela il pourrait convenir de distinguer le modèle de persistence: l'organisation des données en base.

Tout ceci peut d'ailleurs être réalisé sans aucune notion de quel langage que ce soit. Par contre, étant donné que tu pars d'une application Web, une attention particulière sera portée sur la granularité des services et des traitements.

[/ce n'est que mon avis]



... mais ce n'est que mon avis :mouais:

 

[Tarul]

[ce n'est que mon avis]

Pour ma part, je commencerai par analyser mes besoins et essayer de séparer le fonctionnel: les actions à mener du structurel: les structures qui véhicules les données. En cela, l'application existante pourra s'avérer très utile, puisqu'il s'agit d'un portage.

De plus, autant il est bien de s'inspirer de code existant: genre telle fonction comment ont-ils pu faire ?... Mais cela peut s'avérer aussi dangereux: Pour tordre un cadre existant, il faut bien avoir conscience des risques et des limites, sous peine de voire ce cadre tenir guère longtemps et se retrouver prisonnier d'un carcan (image du cadre ).

Donc, pour résumer, je mets d'un coté tout ce dont j'ai besoin:

• identifier les acteurs (qui)
• identifier les services rendus (fait quoi)
• identifier les structures qui vont véhiculer les données pour ces mêmes services (avec quoi)

A cela il pourrait convenir de distinguer le modèle de persistence: l'organisation des données en base.

Tout ceci peut d'ailleurs être réalisé sans aucune notion de quel langage que ce soit. Par contre, étant donné que tu pars d'une application Web, une attention particulière sera portée sur la granularité des services et des traitements.

[/ce n'est que mon avis]


... mais ce n'est que mon avis :mouais:

c'est déjà une trés bonne base comme réflexion.
En programmation si on a analyse mal, on se retrouve a programmer n'importe comment. Et en objet cela peut avoir beaucoups de conséquence puiseque le but de l'objet est de pouvoir réutiliser ce qu'on a déjà créé(ou par d'autres). Et donc un objet mal programmé peut créer des problèmes dans les applis qui l'utilise.

pour en revenir entre la difference entre PHP4 e t PHP5 porte effectivement sur les objets. PHP5 introduit des conceptes objets supplémentaires comme l'heritage qui était inexistant dans PHP4. ce n'est qu'un exemple. Si tu va sur php.net tu verras les changements dans le change log de php5.

Si tu reprends une appli web, avant de faire quoique ce soit, prend bien le temps de l'étudier. Afin d'en faire une critique, et de voir ce que toi tu veux y apporter comme modification.
et mais comme dit Grandibus, ce n'est que mon avis

 

[Bernard Senior]

Pour ma part, je commencerai par analyser mes besoins et essayer de séparer le fonctionnel: les actions à mener du structurel: les structures qui véhicules les données. En cela, l'application existante pourra s'avérer très utile, puisqu'il s'agit d'un portage.

Bon. Attends ! ... Je suis déjà un peu largué ! Tu navigues à trop haute altitude pour moi !
Je te dis ce que je comprends : tu me proposes de (ré)-analyser mon problème. Autrement dit, tu me demandes de coucher sur le papier ce que j'ai dans le ciboulot. En effet, jusqu'à présent, j'ai fait l'analyse au fur et à mesure de la programmation et c'est d'ailleurs, la plupart du temps, les faits dûment constatés qui m'ont forcé à modifier mon application. Exemple : pour le module VPC, je n'avais pas prévu de gérer les stocks, pour la raison que nous ne proposions que des articles (principalement des livres) de notre fonds. En octobre dernier, sur un conseil extérieur, nous avons proposé à nos clients en plus de nos articles, des articles d'autres éditeurs. Et là, catastrophe, évidemment ! Nous avons eu des difficultés de réapprovisionnement chez les éditeurs extérieurs, délais, indisponibilités,... . D'où des commandes bloquées sans aucune possibilité de les enregistrer à l'avance, puisque le programme met systématiquement en expédition toute commande saisie. Puis, quand les articles manquants sont arrivés, nouvelle difficulté pour les servir dans l'ordre des commandes. Comme il y avait plusieurs articles manquants en même temps, cela a engendré une belle pagaille ! Conclusion : il faut modifier le programme !
Ma philosophie n'est pas de faire le programme nec plus ultra mais celui qui colle à la réalité du moment. Evidemment, un changement dans les conditions d'exploitation survenant, cela m'oblige à des modifications. Cela présente néanmoins l'avantage de ne pas me faire développer des fonctions qui à l'usage s'avèrent inutiles.
Pour reprendre ta proposition, je vais essayer d'appliquer tes conseils juste à la gestion du fichier des adresses (pour simplifier). Admettons que je n'ai que 2 niveau d'acteurs : utilisateur lambda et secrétaire. Les trois colonnes sont sensées correspondre à tes 3 points (Bon.. à peu près...pas évident de faire des colonnes. Je n'ai pas le truc)

1 Utilisateur lambda - 2 requêtes consultation - 3 liste/fiche détaillée
1 Secrétaire - 2 requêtes consultation -3 liste/fiche détaillée

2 ajout- 3 fiche détaillée
2 modification - 3 fiche détaillée
2 suppression
​

Est-ce que ça colle ? Ou bien est-ce que je n'ai rien compris ? Faut-il détailler davantage au niveau "fait quoi" et au niveau "avec quoi". Où donc les classes peuvent-elles intervenir ? Au niveau fonctions (services rendus) ?
Et la granularité ? Je ne vois pas trop. Serait-ce de ne pas avoir des classes trop volumineuses ? Mais plutôt de les multiplier en petites classes et sous-classes simples et facilement utilisables ?
En tous cas, merci de ton avis... qui n'est que ton avis

 

[GrandGibus]

Autrement dit, tu me demandes de coucher sur le papier ce que j'ai dans le ciboulot.

Tout à fait. Cela présente les avantages de:

1. mettre du clair dans sa tête... de manière globale (et pas au fur et à mesure )
2. communiquer plus aisément avec d'autres personnes
3. se rendre ainsi compte d'incohérence(s)
4. et surtout d'avoir un excellent point de départ pour les tests, la documentation et la validation

Partant de ce constat, ce n'est vraiment pas une perte de temps !

pour le module VPC, je n'avais pas prévu de gérer les stocks, pour la raison que nous ne proposions que des articles (principalement des livres) de notre fonds. En octobre dernier, sur un conseil extérieur, nous avons proposé à nos clients en plus de nos articles, des articles d'autres éditeurs.

Partons de ce qu'UML appelle les cas d'utilisation. Ce que tu me décris là a tout à fait l'air de ressembler à un nouveau cas d'utilisation. Ainsi, il y a de fortes chances pour que cela se traduise par l'ajout d'un nouveau service au système. Il n'y a pas de raison pour que tes objets ou les autres services soient impactés par l'ajout d'un nouveau service :hein:.

Et là, catastrophe, évidemment !

Je veux bien te croire :rateau:!

D'où des commandes bloquées sans aucune possibilité de les enregistrer à l'avance, puisque le programme met systématiquement en expédition toute commande saisie. Puis, quand les articles manquants sont arrivés, nouvelle difficulté pour les servir dans l'ordre des commandes.

Pour reprendre ton exemple et en amorçant le début d'analyse. Ton système (le logiciel) propose plusieurs services, dont on peut citer:

1. L'authentification
2. La gestion des utilisateurs du systèmes
3. Service d'expédition
4. Service de gestion des commandes

Le détail du service d'authentification pourrait être:

1. boolean login(User user);
2. void logout(User user);

Ici User est abstrait. Ainsi, d'un point de vue du service d'authentification, il n'y a pas de différence entre un utilisateur lambra et une secrétaire !
Cela se traduit en objet par une interface (ou classe de base) User qui a 2 sous-classes dérivées: secrétaire et lambda.

Le détail de gestion des utilisateurs pourrait être:

1. void addSecretaire(String name, String password); // le nom doit être unique dans le système, sinon exception
2. void addLambda(String name, password);
3. void remove(String name);

Remarque, il n'apparaît nulle part des notions d'ID ou de design de base de données... ce n'est que bien plus loin dans les détails d'implémentation qu'il faudra se pencher sur ce point.

Le détail du service de gestion des commandes pourrait être:

1. Command createCommand(String name);
2. void addArticle(Command cmd, Article art);
3. void removeArticle(Command cmd, Article art);

Ici encore, Article doit être une notion abstraite pour les mêmes raisons évoquées précedemment.

Evidemment, un changement dans les conditions d'exploitation survenant, cela m'oblige à des modifications.

Pas forcément. En utilisant le bon niveau d'abstraction avec Article et User .... c'est à ça que ça sert l'objet !

Ma philosophie n'est pas de faire le programme nec plus ultra mais celui qui colle à la réalité du moment.

L'analyse nec plus ultra sera ton meilleur investissement . Tu auras tout le temps pour peaufiner l'implémentation (le passage aux lignes de code) et ainsi aboutir au programme nec plus ultra.


Si tu as tout dans ta tête, et vu la taille de ton application, tu ne devrais pas en avoir pour longtemps à ainsi faire l'analyse de ta problématique. De plus, à première vue, ton application ne semble pas avoir de problématiques inconnues... à savoir qu'on reste quand même dans des problématiques d'informatique de gestion très classiques, et donc, à ce titre, peut-être que des ouvrages d'analyse pourraient te montrer la voie.

C'est aussi sur la base de cette analyse que tu pourras définitivement décider s'il vaut mieux partir sur l'utilisation et le paramétrage de progiciel existants, ou bien partir sur la voie du développement maison ! (et la boucle est bouclée).

 

[Bernard Senior]

Tout à fait. Cela présente les avantages de:

1. mettre du clair dans sa tête... de manière globale (et pas au fur et à mesure )
2. communiquer plus aisément avec d'autres personnes
3. se rendre ainsi compte d'incohérence(s)
4. et surtout d'avoir un excellent point de départ pour les tests, la documentation et la validation

Partant de ce constat, ce n'est vraiment pas une perte de temps !

Un grand merci de passer du temps avec un béotien comme moi. Tu clarifies plein de choses. Peut-être bien que c'est toi qui nous vaut les 5 étoiles qui sont apparues hier sur ce fil.
Je vais me mettre sérieusement à coucher sur le papier l'analyse de mon problème et ainsi mettre en application tes conseils.

 

[Gabone]

Merci, pour votre poste qui est très enrichissant pour moi. Et qui m’a bien aidée.