Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Page 2 sur 334 PremièrePremière 123456789101252102 ... DernièreDernière
Affichage des résultats 31 à 60 sur 10008
  1. #31
    Ne t'inquiète pas, il y en a qui ne sont pas vraiment méchants. Tu as encore un espoir que le bashing que tu va subir ne soit pas trop violent. Enfin si ton code est nickel pour commencer, sinon c'est pas la peine, tu peux commencer à courir.

  2. #32
    Ou alors on va juste m'ignorer.
    "Dieu est mort" · "Si le téléchargement c’est du vol, Linux c’est de la prostitution."

  3. #33
    Pour préciser mon histoire de SGBD
    Un produit est décrit par
    ID|nom|catégorie|prix
    sachant qu'un produit n'est que dans une catégorie et n'en changera jamais, et ya rarement plus de 10 produits par catégorie.

    Voila, vous pouvez continuer à vous entretuer
    Exterminate !

  4. #34
    Et il n'y a QUE ces quatre propriétés dans toute la base de données?

    C'est un truc "amateur" (c'est pas péjoratif hein )?

  5. #35
    Oui que ça, c'est pour un projet perso pas pour la NASA.
    je peut pas inventer des données qui n'existe pas
    Exterminate !

  6. #36
    Ben si, fait comme au boulot. Pour les noms des colonnes, tu prends entre trois et six lettres au hasard, en suffixant par "_key" ou "_id" de temps en temps.
    "Dieu est mort" · "Si le téléchargement c’est du vol, Linux c’est de la prostitution."

  7. #37
    Citation Envoyé par rOut Voir le message
    Ben si, fait comme au boulot. Pour les noms des colonnes, tu prends entre trois et six lettres au hasard, en suffixant par "_key" ou "_id" de temps en temps.
    :')

    Plus sérieusement, si tu n'as vraiment que ces 4 données là et que tu es certain que ça ne bougera pas, à mon avis tu peux te contenter d'une seule table.
    Je sais, ça ne fait pas pro, mais bon...

    Après, le faire avec plusieurs tables dès le début, ça te permet de faire évoluer ton projet (on sait jamais) par la suite plus facilement.

  8. #38
    Citation Envoyé par rOut Voir le message
    Ben si, fait comme au boulot. Pour les noms des colonnes, tu prends entre trois et six lettres au hasard, en suffixant par "_key" ou "_id" de temps en temps.
    :')

    Plus sérieusement, si tu n'as vraiment que ces 4 données là et que tu es certain que ça ne bougera pas, à mon avis tu peux te contenter d'une seule table.
    Je sais, ça ne fait pas pro, mais bon...

    Après, le faire avec plusieurs tables dès le début, ça te permet de faire évoluer ton projet (on sait jamais) par la suite plus facilement.

  9. #39
    Sinon, comme les autres, peu importe que t'as rien à y mettre, tu fais deux tables point barre.

    Ca t'évitera de te planter en rentrant un produit avec une typo sur la catégorie, et de ne plus le retrouver au bon endroit (ou d'avoir plus de catégories que prévu). Une table de catégories avec la liste précise des catégories disponibles, chacune avec un id.
    Une table des produits, avec leur id.

    Et après au choix, une colonne dans la table des produits avec l'ID de la catégorie associée, ou une table de plus avec une colonne ID du produit, une autre ID de la catégorie. La table est mieux pour une vision à long terme, si tu décides un jour que tes catégories sont en fait des tags et qu'on peut en mettre plusieurs pour un produit (les catégories strictes c'est les années 90).
    "Dieu est mort" · "Si le téléchargement c’est du vol, Linux c’est de la prostitution."

  10. #40
    Citation Envoyé par rOut Voir le message
    Sinon, comme les autres, peu importe que t'as rien à y mettre, tu fais deux tables point barre.

    Ca t'évitera de te planter en rentrant un produit avec une typo sur la catégorie, et de ne plus le retrouver au bon endroit (ou d'avoir plus de catégories que prévu). Une table de catégories avec la liste précise des catégories disponibles, chacune avec un id.
    Une table des produits, avec leur id.

    Et après au choix, une colonne dans la table des produits avec l'ID de la catégorie associée, ou une table de plus avec une colonne ID du produit, une autre ID de la catégorie. La table est mieux pour une vision à long terme, si tu décides un jour que tes catégories sont en fait des tags et qu'on peut en mettre plusieurs pour un produit (les catégories strictes c'est les années 90).
    Cet homme parle vrai.
    Et peu importe la taille ou le côté pro ou non d'un projet, c'est toujours idiot de se priver d'une possibilité d'évolution parce qu'on a voulu faire "au plus vite au mieux".

  11. #41
    Merci je vais faire comme ça

    Quand à la question sur les frameworks php, un seul vaut le coup et c'est Django
    Exterminate !

  12. #42

  13. #43
    Citation Envoyé par magn3tik Voir le message
    Django, en php ?
    Exactement. Comme Rails.

    Dans le secteur pro, et en France, les deux frameworks PHP ayant le vent en poupe sont principalement Symphony et Zend Framework. Personnellement, j'ai choisi le second ; il exige plus d'efforts de compréhension et d'adaptation que le premier (il s'agit avant tout d'une bibliothèque de classes faiblement couplées, hormis évidemment celles qui constituent le cœur MVC), donc on est moins productif avec dans un premier temps, par contre c'est rattrapé ensuite par la possibilité de se faire son framework à soi aux petits oignons. Symphony est beaucoup moins souple à ce niveau, il est plus difficile de se soustraire de certains choix techniques faits dans sa conception qu'on trouverait mal gaulés ou inadaptés au but à atteindre.

    Le choix de l'un ou l'autre dépend donc vraiment du temps qu'on peut consacrer à son étude/adaptation, si on travaille en équipe, de son niveau en POO, de la nature des applis à développer, bref de plein d'autres facteurs qui ne sont pas toujours techniques.

  14. #44
    Ouais de toute façon, j'ai vraiment l'impression que ça devient obligatoire pour pouvoir postuler en dev PHP

    Sinon pourquoi deux tables (catégories et produits) au lieu d'une ?
    Parce que c'est plus propre, et que forcément tu vas faire un menu avec les catégories quelque part pour la navigation, la requête
    Code:
    SELECT `id`,`nom` FROM `categories` ORDER BY `nom`
    sera toujours plus rapide que
    Code:
    SELECT DISTINCT `categorie` FROM `produits` ORDER BY `categorie`
    Et de même pour les requêtes affichant les produits.

  15. #45
    Y'a Code Igniter aussi en framework PHP pas trop mal. J'ai eu l'occasion de travailler avec leur classe image en tout cas dans mon ancien taf (framework fait maison avec emprunts de classes open source à gauche à droite) et c'était vraiment bien foutu.

    Sinon oui, souvent les offres d'emploi pour dev PHP mentionnent Zend, ou Drupal, pour la plupart.

  16. #46
    Tient, C++0x a enfin été finalisé par l'ISO.

  17. #47
    C'est C++11 du coup ?

    Ça correspond au draft de février 2011, ou il y a eu d'autres changements depuis ?

  18. #48
    http://herbsutter.com/2011/08/12/we-...usly-approved/
    Aucune idée autrement.

    edit: d'apres wiki, draft du 5 avril 2011.

  19. #49
    Oh yeah.

    Enfin c'était un peu une formalité.
    "Dieu est mort" · "Si le téléchargement c’est du vol, Linux c’est de la prostitution."

  20. #50
    Formalité qui a pris 10 ans, normal quoi.

    Ce qui est amusant (ou pas), c'est que certaines parties de la norme sont déjà obsolètes. Par exemple ils ont adopté les « nouvelles » fonctions arithmétiques de C99… Sauf qu'entre temps c'est IEEE-754 qui a été révisée, et certaines parties de la libm C99 sont un peu à côté de la plaque.

  21. #51
    Je parlais de la validation finale. Le gros des efforts avait été fait depuis quelques mois.

    Sinon, vu le temps que ça prend, c'est assez normal qu'il y ait des trucs obsolètes. Il y a eu pas mal de coupes franches aussi, mais heureusement il reste quelques trucs sympas
    "Dieu est mort" · "Si le téléchargement c’est du vol, Linux c’est de la prostitution."

  22. #52
    Mouais, quelques trucs sympas, mais des omissions énormes. Ce qui était compliqué, chiant et nid à bugs le sera toujours. M'enfin c'est bien que l'ISO ait apposé son tampon.

  23. #53
    Des omissions, tu parles des concepts ? du garbage collection ? de la reflection ?
    "Dieu est mort" · "Si le téléchargement c’est du vol, Linux c’est de la prostitution."

  24. #54
    Pas forcément, même s'ils auraient pu améliorer le support des informations à l'exécution (par exemple pouvoir tester si deux types sont liés par héritage).
    Je pensais à des choses simples, en vrac et de manière non exhaustive: les templates sont un peu bricolés, il serait intéressant de pouvoir contraindre les arguments à dériver d'une classe, pouvoir écrire des constructeurs statiques, pouvoir mieux gérer les objets de taille variable en évitant des allocations qui pourrissent le tas (le move constuctor/operator est un pas), pouvoir définir un type comme terminal (ce qui aiderait le compilateur pour les optimisations), des choses comme ça.

  25. #55
    Les contraintes sur les templates c'était un peu le principe des concepts. Mais l'objectif était peut être trop ambitieux.
    Enfin tu peux toujours faire comme c'est actuellement avec les type traits. Enfin ça nécessite que les types que tu manipules exposent les méta données nécessaires, mais ça se fait. (J'ai une librarie de vérification statique autour des appels OpenGL qui fait ce genre de choses).

    Qu'est ce que tu veux dire par constructeurs statiques ?
    "Dieu est mort" · "Si le téléchargement c’est du vol, Linux c’est de la prostitution."

  26. #56
    Euhh oui ça se fait, mais justement c'est lourd, compliqué à comprendre parce que non standard donc chaque développeur / bibliothèque a son fonctionnement propre et cela impose des contraintes sur les classes que tu manipules, ce qui peut t'obliger à dériver tes propres classes à partir de classes pré existantes etc...
    Et de toutes façons, la vérification se fait trop tard même si 0x apporte quand même un plus du côte de l'instanciation des templates. (En fait oui, les concepts couvrent le besoin, mais en allant trop loin).

    Constructeur statique = fonction statique exécutée dans la phase d'initialisation du programme. Permet d'avoir le code d'initialisation global de chaque classe dans celles-ci. La aussi ça se fait sans problème (avec une variable statique d'une classe dédiée "amie" dont le constructeur fait l’initialisation) mais ça complique la lecture, la compilation, la compréhension et on finit toujours par faire le copier/coller fatal et par coller un bug dedans. Qui plus est cela fonctionne mais n'est pas garanti par la norme C++ (la plupart des compilateurs calculent l'ordre dans lequel exécuter le code statique, mais ce n'est pas imposé par la norme). Le genre de truc pratique pour coder proprement une factory. Et tant qu'à faire, un peu de réflexion faciliterait encore plus la tâche !

  27. #57
    Tu n'as pas forcément besoin de modifier les classes sur lesquelles tu veux faire de la vérification statique, tu peux utiliser un framework de classes orthogonales, comme c'est le cas avec Boost.TypeTraits.
    Par exemple, tu as une classe template nommée "has_trivial_destructor" qui va te permettre de déterminer si la classe passée en paramètre a un destructeur trivial ou non. Par défaut, le template hérite de false_type, mais tu peux le spécialiser pour les classes que tu veux indiquer comme ayant un destructeur trivial, et dans ce cas, has_trivial_destructor< MaClasse > héritera de true_type. MaClasse n'est pas modifiée et reste propre de toute métadonnée, on a juste spécialisé le template has_trivial_destructor quelque part dans le code.

    Sinon je ne vois pas bien comment la vérification peut se faire trop tard. Personellement ma vérification statique génère des messages d'erreur à la compilation (avec un vrai message d'erreur grâche au static_assert du C++11). On peut difficilement faire plus tôt.

    Pour le constructeur statique, tu as des pattern de singleton qui assurent que la classe sera instanciée, avant même que l'execution entre dans le main. Si tu as besoin d'avoir un certain ordre, il suffit d'utiliser une instance d'un autre singleton dans le constructeur pour t'assurer que celui ci sera instancié avant le singleton courant.
    L'implementation de chez Boost : http://www.boost.org/doc/libs/1_47_0.../singleton.hpp, bon y'a quelques prérequis, mais c'est quand même pas trop contraignant (un seul thread tournant avant l'entrée dans main, et après la sortie du main, la classe doit avoir un constructeur par défaut).
    "Dieu est mort" · "Si le téléchargement c’est du vol, Linux c’est de la prostitution."

  28. #58
    Bah il y a des moyens d'y arriver, et je te suis, le static_assert permet de faire des choses à la compilation c'est un bon progrès. Mais boudiou que c'est compliqué pour donner des contraintes simples ! voir ce que proposait Ada il y a 25 ans.
    Mais je suis d'accord avec toi, maintenant avec 0x tu peux plus facilement gérer (instanciation des templates + static_assert).

    Constructeur statique, je te ferais la même réponse: oui tu peux utiliser des patterns qui te simplifient la vie, l'implémentation que tu indiques reprend le principe que j'énonçais en le rendant générique, mais bordel, ce serait quand même plus simple de pouvoir juste écrire
    Code:
    static MaClasse();
    non ?
    D'ailleurs, l'implémentation boost illustre ce que je reproche au niveau des vérifications de template : voir les lignes suivantes
    Code:
          // The following line does nothing else than force the instantiation
          //  of singleton_default<T>::create_object, whose constructor is
          //  called before main() begins.
          create_object.do_nothing();
    En fait, je fais du C++ depuis 20 ans, j'apprécie énormément ce langage mais j'ai constaté avec le temps qu'il est en voie de disparition parce que trop dur à maîtriser et à apprendre. Tout ce qui rend son utilisation plus simple et plus immédiate serait bon à prendre, même si je comprends que le comité répugne à faire évoluer le langage pour des fonctionnalités qu'on peut obtenir avec des bibliothèques.

  29. #59
    A vrai dire, je pense que la dépréciation du C++ n'est pas quelque chose à laquelle peut rémédier le commité. Rajouter des contraintes sur les templates ou ajouter la possibilité d'avoir des constructeurs statiques, ce n'est pas ça qui va attirer les gens, au contraire. Ce sont à mon avis des fonctionalités réservées aux programmeurs avancés, ceux qui maîtrisent déjà la complexité du C++ et qui perçoivent ses limitations.

    Si le C++ est de moins en moins à la mode, c'est parce que les jeunes sortant d'école d'info n'ont été formés qu'à faire du Java ou du C#, afin de pouvoir être productifs rapidement. Lorsque l'on voit des cours de C++ en école, ça se limite généralement à la programmation objet (je pense avoir eu de la chance d'avoir eu quelques cours de métaprogrammation qui m'y a donné gout, mais mon prof de C++ était un peu allumé). Et dans ce cas, autant faire du Java, t'auras moins d'emmerdes avec la mémoire. La plupart des boites d'info n'ont pas envie de s'emmerder avec du C++, parce que les gens qui savent en tirer toute la saveur coûtent chers, et on veut pouvoir interchanger les développeurs, que chacun puisse reprendre le code de l'autre. Et pour reprendre un code bourré de métaprogrammation, il faut avoir des développeurs qui comprennent comment ça marche.

    Prends par exemple le langage D. Beaucoup des faiblesses du C++ ont été "corrigées", on a même droit à un garbage collector sur du code compilé... pourtant personne ne fait du D. Tout simplement parce que toutes ces fonctionalités sont trop avancées et jamais utilisées dans la plupart des boites.

    Après je pense qu'il y aura toujours des domaines ou le C++ sera incontournable. Perso, la programmation object j'en fait depuis 10ans, et j'en ai un peu ma claque ; les templates c'est une autre façon de voir les choses, un vrai langage derrière le langage.
    "Dieu est mort" · "Si le téléchargement c’est du vol, Linux c’est de la prostitution."

  30. #60
    Je pense qu'on se rejoint, C++ est de moins en moins utilisé parce qu'il nécessite beaucoup d'expérience; c'est un langage puissant mais très exigeant.
    C'est déjà pas facile à apprendre, encore moins à maîtriser (nous avons tous des exemples de bugs infernaux à sortir, le premier que je me sois tapé il y a longtemps était un memory leak à cause d'n destructeur déclaré non virtuel: c'est un exemple édifiant de la difficulté à maîtriser le bestiau).
    Aujourd'hui pour développer sérieusement en C++, il faut non seulement maîtriser la complexité du langage mais aussi connaître les bibliothèques standard plus des Frameworks complétant l'ensemble. J'espérais une évolution du langage qui simplifierait le développement (pour reprendre mes 2 exemples éviter d'utiliser un pattern via des classes templates par simple utilisation d'un mot clé).

    Cela dit, je ne critique pas la nouvelle norme, le C++ oit être le langage le plus ch... à compiler et minimiser les extensions du langage est gage d'adoption facile de la norme.

    P.S. Les templates ne sont pas pour moi une alternative à la programmation objet, les approches me semblent fortement complémentaires (les génériques me manquaient avec les langages purement objets, les objets me manquaient en Ada) ?!

    ---------- Post added at 17h02 ---------- Previous post was at 17h01 ----------

    pis sinon on va peut-être éviter de monopoliser le topic avec un sujet qui a du être débattu 8000 fois

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •