Écoutes beaucoup les autres !
Montres que tu tiens compte de leur avis et ne fais pas dans le :
- tous sauf MS.
Bref, ne soit pas intégriste ! C'est hyper important sinon les gens se braquent.
Utilises PostgreSQL au-lieu de MySQL. A l'utilistation pour de petit projet c'est pas plus compliqué mais si tu as besoin de fonctionnalités avancées elles sont là.
Et en fonctionnalité avancée, il faut pas chercher bien loin pour avoir besoin de PostgreSQL. PostgreSQL est meilleur pour la gestion de date, i18n, etc. Il y a aussi le type coordonnée (et des opérateurs) qui peut-être pratique pour ton projet.
Je vais être un intégriste :-) mais quit à apprendre un nouveau SGDB, commences par PostgreSQL.
Utilises les "standards". C'est beaucoup plus facile à maintenir et ça t'évite de faire des docs de 12 kilomètres. Si PostreSQL (par exemple) est fournit dans la distribution, ne fais pas une installation depuis les sources (ou depuis cooker/rawhide/etc) pour avoir la dernière version. C'est de la pure connerie, c'est une perte de temps énorme pour rien et les autres vont te regarder de travers en te voyant jouer au "sorcier".
Ceci dit, parfois c'est nécessaire :-)
> zope
Je suis toujours très hésitant avec ce type de produit. J'ai investi beaucoup de temps à une époque pour évaluer zope et midgard. Et à chaque foi, je tombais sur un détail technique qu'il était difficile de contourner pour mon projet.
Finalement, j'ai utilisé phplib dont beaucoup template (pas templeet :-)).
C'est toujours le même débat entre 4gl et outils bas niveau. Si ton projet est assez complexe, s'orienté vers le "bas niveau" peut-être un bon chois. Par contre, au début il faut s'arracher. En effet, au début, les autres ont l'impression que le projet n'avance pas et que tu perds beaucoup de temps avec un outil bas niveau. Puis une fois que tout est en place, c'est "wouhaaa".
Mais attention, c'est compliqué. Il faut savoir faire un bonne conception et prendre en compte dès le début les évolutions les plus probables. Il faut préparer le terrain pour de futur victoire :-)
Donc si t'es un bon développeur et que tu aimes ça (car parfois on s'arrache les cheveux), éviter zope/midgard/etc peut-être un bon choix.
Sur un projet, c'est au début qu'il faut s'arracher à fond ! Étude du besoin, rencontre des utilisateurs, ébauche de solution, cahier des charges, conception sur le papier.
Si tu assures à cette étape qui est assez pénible quand on aime coder, le reste roule tranquillement et tu peux lever le pied.
Fais attention lorsque tu élabores un projet. En général le délais qu'on s'accorde est toujours trop court.
Donc augmentes les délais et peut-être que tu feras la surprise d'être en avance sur le planning.
Ne sous-estimes pas le temps nécessaire vers la fin du projet. C'est toujours là que des petits problèmes difficiles à trouver ou corriger arrivent ou qu'il y a des demandes nouvelles d'utilisateurs de priorité 0 (comme par hazard...). Donnes toi une bonne période pour finaliser/tester le projet.
Fais du beau code, maintenable, modulaire, etc et dès le début. Le temps que tu "perds" au début n'est absolument pas perdu. Tout le monde te le dira (ou presque).
# Conseil
Posté par 007 . En réponse au journal Quel framework?. Évalué à 9.
Montres que tu tiens compte de leur avis et ne fais pas dans le :
- tous sauf MS.
Bref, ne soit pas intégriste ! C'est hyper important sinon les gens se braquent.
Utilises PostgreSQL au-lieu de MySQL. A l'utilistation pour de petit projet c'est pas plus compliqué mais si tu as besoin de fonctionnalités avancées elles sont là.
Et en fonctionnalité avancée, il faut pas chercher bien loin pour avoir besoin de PostgreSQL. PostgreSQL est meilleur pour la gestion de date, i18n, etc. Il y a aussi le type coordonnée (et des opérateurs) qui peut-être pratique pour ton projet.
Je vais être un intégriste :-) mais quit à apprendre un nouveau SGDB, commences par PostgreSQL.
Utilises les "standards". C'est beaucoup plus facile à maintenir et ça t'évite de faire des docs de 12 kilomètres. Si PostreSQL (par exemple) est fournit dans la distribution, ne fais pas une installation depuis les sources (ou depuis cooker/rawhide/etc) pour avoir la dernière version. C'est de la pure connerie, c'est une perte de temps énorme pour rien et les autres vont te regarder de travers en te voyant jouer au "sorcier".
Ceci dit, parfois c'est nécessaire :-)
> zope
Je suis toujours très hésitant avec ce type de produit. J'ai investi beaucoup de temps à une époque pour évaluer zope et midgard. Et à chaque foi, je tombais sur un détail technique qu'il était difficile de contourner pour mon projet.
Finalement, j'ai utilisé phplib dont beaucoup template (pas templeet :-)).
C'est toujours le même débat entre 4gl et outils bas niveau. Si ton projet est assez complexe, s'orienté vers le "bas niveau" peut-être un bon chois. Par contre, au début il faut s'arracher. En effet, au début, les autres ont l'impression que le projet n'avance pas et que tu perds beaucoup de temps avec un outil bas niveau. Puis une fois que tout est en place, c'est "wouhaaa".
Mais attention, c'est compliqué. Il faut savoir faire un bonne conception et prendre en compte dès le début les évolutions les plus probables. Il faut préparer le terrain pour de futur victoire :-)
Donc si t'es un bon développeur et que tu aimes ça (car parfois on s'arrache les cheveux), éviter zope/midgard/etc peut-être un bon choix.
Sur un projet, c'est au début qu'il faut s'arracher à fond ! Étude du besoin, rencontre des utilisateurs, ébauche de solution, cahier des charges, conception sur le papier.
Si tu assures à cette étape qui est assez pénible quand on aime coder, le reste roule tranquillement et tu peux lever le pied.
Fais attention lorsque tu élabores un projet. En général le délais qu'on s'accorde est toujours trop court.
Donc augmentes les délais et peut-être que tu feras la surprise d'être en avance sur le planning.
Ne sous-estimes pas le temps nécessaire vers la fin du projet. C'est toujours là que des petits problèmes difficiles à trouver ou corriger arrivent ou qu'il y a des demandes nouvelles d'utilisateurs de priorité 0 (comme par hazard...). Donnes toi une bonne période pour finaliser/tester le projet.
Fais du beau code, maintenable, modulaire, etc et dès le début. Le temps que tu "perds" au début n'est absolument pas perdu. Tout le monde te le dira (ou presque).
Bonne chance.