gaaaaaAab a écrit 1401 commentaires

Il y a une petite ambiguïté sur le titre de ta question, et ce n'est pas anodin. Modifier le schéma (le faire évoluer ponctuellement pour faire face à des nouveaux besoins), c'est une opération relativement courante. Modifier dynamiquement le schéma (l'application utilise directement des commandes de DDL[1] pour modifier le schéma à la volée), c'est plutôt casse gueule.

Dans ton cas, je pense qu'il s'agit de modifier ponctuellement la structure de la base de données. L'ajout d'une table ou d'un champ dans une table n'est a priori pas susceptible d'entraîner une corruption des données, ce qui n'interdit pas de faire une sauvegarde ponctuelle avant la modification (parce que c'est de toute façon une bonne pratique).

Je trouve difficile de juger de la pertinence d'ajouter une colonne ou une table dans ton cas, parce que ça dépend des enjeux à long terme. Si la donnée calculée n'a vraiment de sens fonctionnel qu'à un instant T, donc que conserver les calculs des mois précédents n'a aucun intérêt, une simple colonne pourrait suffire. Si l'évolution de cette donnée dans le temps est fonctionnellement intéressante, ajouter une table peut être intéressant.

Bref, modifier ponctuellement la structure de la base de donnée pour répondre à un nouveau besoin est une opération tout à fait classique. Les moteurs de gestion de base de données sont fait pour ça, pas de problème.

Ajouter une table ou une colonne semblent permettre de répondre au besoin. Chaque solution a ses avantages et inconvénients.

1.Ajout de colonne :

• avantages :
  • structure de donnée plus simple
  • interface de visualisation des données plus simple
• inconvénient :
  • idéalement, il faut trouver un moyen d'indiquer à l'utilisateur la date des derniers calculs, pour ne pas l'induire en erreur (par exemple en début de mois)
  • (inconvénient potentiel) pas d'historisation

2.Ajout de table :

• avantages :
  • données historisées
• inconvénients :
  • structure plus complexe
  • (inconvénient potentiel) interface de visualisation plus complexe si on veut présenter les données historisées à l'utilisateur

Re bref (hmmm pas si sûr que ça soit bref :D ) : Modifier la structure de donnée est une manipulation techniquement anodine. Dans ton cas, les deux solutions (ajout de table ou ajout de colonne) permettent une réponse technique à ta question. Du coup, le choix entre ces deux solutions ne peut pas se faire sur un critère purement technique. C'est donc en regardant le contexte global de l'application qu'il faudra choisir entre ces deux solutions.

D'autre part, si les calculs sont suffisamment simples et les données pas trop volumineuses, un calcul à la volée à chaque consultation pourrait aussi peut-être répondre au besoin.

Voilà, je suis tout à fait conscient que je n'ai absolument pas répondu à ta question (ou plutôt que je t'ai répondu de trouver la réponse tout seul ;) ) mais j'espère que tu trouveras quand même matière à réflexion dans ce commentaire.

[1] point acronyme: le DDL (Data Definition Language) permet de modifier la structure d'une base de données. Le DML (Data Manipulation Language) permet de manipuler les données (insertion, modification, suppression, requête)

en est-on bien sûr ? cf là histoire de ne pas me répéter

J'attends la démonstration de comment on peut faire une boite noire libre.

D'un point de vue théorique, en obscurcissant (obfuscate en anglais, c'est pas un jeu de mot débile obscure -> noir) du code libre ?
Dans le même genre, je me souviens d'un article dans M.I.S.C. qui traitait de recherches visant à implémenter des dispositifs de DRM en boite blanche.

On sort un peu du cadre du débat sur systemd, mais c'était juste pour répondre sur ce point en passant.

C'est quoi cette façon d'apporter la preuve par les faits ?

Tu noteras que je n'ai pas donné mon avis, mais simplement un lien. Je ne connais pas suffisamment systemd pour déterminer s'il y a une grande distance entre ce post et ce que systemd est aujourd'hui (et puis c'était un peu long, j'ai plutôt survolé. Possible que je relise plus en profondeur à l'occasion).

Du coup, tout va bien, je suis sûr qu'il reste largement de quoi s'écharper sur son interprétation !

cf http://linuxfr.org/users/thom/journaux/gol-en-a-ras-le-bol-des-gogols

il y aurait un exemple cité par
http://www.gamingonlinux.com/articles/i-am-moving-on-from-gamingonlinux.4416

Venn Stone in particular is just a hate spreading tool who uses Linux Torvald quotes about offending people to back himself up, and to make himself feel important.

j'imagine que ça a été ajouté après la publication de ton journal.

UPDATE: I am still writing for Linux Voice, and I will be in the background here as a lurker/site coder, but I will not be contributing articles directly. Samsai is currently taking the reigns.

soit (vite traduit)

J'écris toujours pour Linux Voice, et je resterais dans les coulisses ici en tant que visiteur/développeur du site, mais je ne contribuerai plus d'articles directement. Samsai prend les rênes.

ah oui, parfois aussi, je lis du code moche, et je me dis, "mais celui qui a écrit ce truc là, vaudrait mieux qu'il arrête le dév tout de suite", et parfois, c'est moi !

Si je dis "je ne connais pas le batard qui a mis ce poteau ici, mais si je le croise je lui pète les genoux", tu ne considèreras pas ça comme violent ?

beaucoup moins que "si je te croise, je te pète les genoux". Pour prendre un exemple 3615 mavie : une fois, en montagne en hiver et en altitude, je sens une odeur de clope. Je ne peux pas retenir un "mais c'est qui le connard qui fume", parce que j'aime bien l'air pur, la montagne, les petits oiseaux toussa. Bon, il se trouve que le fumeur se trouvait à 2 mètres de moi, je me suis senti con. Pourquoi ? parce que quand je dis "c'est qui le connard qui fume", en fait, je m'en fous de savoir qui c'est, j'exprime juste que ça me pourrit le moment. Et je le dis pas non plus pour qu'il l'entende, il a le droit de fumer en plein air, et j'ai le doit que ça me soule. Fin de l'histoire (oui, j'ai une vie passionnante :) )

C'est d'ailleurs assez rigolo, tu demande juste au dessus des exemples de gens qui prennent le comportement d'autres exemple pour se dédouaner.

ok, je l'ai mal formulé, je réessaie. Ce que je veux dire c'est que si les excès "verbaux" de Linus avait un effet négatif global, on pourrait s'attendre à ce que les insultes fusent en permanence, comme par exemple sur des sites généralistes, et il ne me semble pas que ça soit le cas. J'ai bien conscience que c'est une impression que je ne peux pas étayer par une quelconque enquête sociologique. Il faudrait comparer avec ce qui se passe dans d'autres communautés non liés au logiciel. En même temps, rien que dans le LL, il y a des communautés plus ou moins rugueuses. Du coup, j'aurais quand même tendance à penser que l'influence des expressions imagées de Linus est plutôt faible.

Pour vous départager, autant aller voir la source

Pour revenir au message source, je ne suis pas du tout sûr que Linus connaisse l'identité de la personne cible de son courroux. En tout cas, dans son message, il ne dit pas "Tu devrais être rétroactivement avorté", mais (traduction libre) "le quelconque génie qui a pensé que c'était une bonne idée (…) devrait être rétroactivement avorté". Dans son message, Lennart ne précise pas que Linus s'en prend à un dév de systemd, et vu la réponse de Kay, j'aurais aussi tendance à penser qu'il l'a pas pris pour lui (ou en tout cas, qu'il ne s'en est pas plus offusqué que ça). Faudrait aussi voir à ne pas être plus royaliste que le roi.

Pour le fond de la question, est-ce que le comportement de Linus donne le mauvais exemple, je n'en sais rien. Je ne me souviens pas avoir lu de messages de gens justifiant leurs insultes en citant explicitement Linus comme exemple. Si quelqu'un a ça sous la main, ça contribuerait utilement au débat.

Il me semble aussi que les insultes sont largement plus virulentes dans les commentaires de sites de presse généraliste que sur les mailing list / forums / … de la communauté mais bon …

C'est une couche de sécurité supplémentaire (épaisseur genre nuisette), mais qui est totalement insuffisante toute seule en 2014.

D'après Alan Cox, c'était aussi insuffisant tout seul en 2007, la raison étant que chroot n'a pas été conçu pour servir de couche de sécurité. On ne peut pas reprocher à un outil de ne pas répondre à un besoin auquel il ne cherche pas à répondre.

Dans la vie quand on a un marteau, les problèmes ressemblent tous à des clous.

pour terminer le proverbe, "et quand ton marteau, c'est C++, tout ressemble à un doigt" ! :D

le terminal c'est pour les serveurs, les GEEKs,
ou pour se la peter devant les collegues en disant, regarde, moi je "maitrise" linux.

c'est triste ton avis sur le terminal

En farfouillant sur le net, j'ai trouvé des infos supplémentaires.

cf le premier message de http://www.gossamer-threads.com/lists/python/dev/651981

Si tu es en Python 2, tu peux t'en sortir simplement en ne dérivant pas ta classe de object (j'ai testé, ça marche).

Sinon, j'ai aussi trouvé une recette pour python 3. Cette recette fonctionne un peu différemment parce qu'elle crée des proxy sur des objets instanciés, et pas sur des classes. En reprenant l'exemple, comme ça, chémoisamarche :

c=Proxy(list())
c.append(3,)
print ("value : " + str(c[0]))

Mais ai-je un moyen de savoir si les méthodes magiques sont implémentées ?

oui, la fonction dir liste tous les attributs de ce qu'on lui passe en paramètres.

C'est une des raisons pour lesquelles je n'aime pas Python ( et Java également) : il complique les choses qui se font de façon simple et évidentes dans d'autres langages.

et vice et versa !

J'avais dit à une époque que je trouvais que Python était un langage qui force à se répéter, et voici un exemple typique de ce que je voulais dire.

ça ne correspond pas à mon expérience. C'est vrai qu'en étant confronté à des nouveaux problèmes, il m'a parfois fallu un peu de temps pour trouver comment faire, mais j'ai toujours réussi à atteindre un truc que je trouvais propre en Python.

Entendons-nous bien : je ne veux pas "cracher" sur Python. J'avais juste promis il y a quelques temps que je donnerais des raisons concrètes pour lesquelles je trouvais que Python force à se répéter, et en voilà un concret.

raison suivante stp (ou un autre exemple de répétition) :-)

Si elle existe, je ne l'ai pas vue, mais j'ai peut-être mal cherché.

En fait, j'ai pas trouvé non plus, mais c'est p-e parce que c'est pas comme ça qu'on ferait en Python. Tu peux peut-être t'en sortir avec un décorateur qui fabriquerait à la volée des classes dérivées des types qui t'intéressent avec les ajustements dont tu as besoin. Autrement dit, au lieu d'encapsuler ta classe dans un proxy générique, est-ce que ça serait pas plus simple d'avoir un générateur de classes proxy spécialisées ?

Attention, __getattr__ est censé renvoyé la valeur d'un attribut. Ton implémentation actuelle renvoie une méthode qui renvoie la valeur de l'attribut pour _obj. Est-ce que tu ne voudrais pas plutôt faire ? :

    def __getattr__(self,name):
        return getattr(self.__dict__['_obj'],name)

Pour l'appel direct c[0], de ce que j'ai testé, l'interpréteur utilise la méthode __getitem__, mais en l'appelant directement, sans passer par __getattr__. Du coup, tu peux t'en sortir en ajoutant la méthode:

    def __getitem__(self, key):
        return self.__dict__['_obj'].__getitem__(key)

Si tu veux pouvoir affecter un élément de la liste, il faut que tu ajoutes aussi __setitem__. Bref, pour faire propre, il faudrait ajouter tous les __<methode>__ de la classe qui t'intéresse (inclus __repr__ et __str__ pour faire joli).

Mais du coup, tu te retrouves avec un proxy spécialisé pour les listes, ce qui n'est pas forcément ce que tu veux. L'étape d'après est de lister tous les attributs de la classes que tu veux proxifier, et rajouter les méthode __*__ dont tu as besoin à l'instanciation. Et du coup, il y a surement une recette quelque part sur le net.

Edit: je vois que je répond un peu à côté de la question sur les __getitem__ et compagnie

nous sommes un fond macro, autrement dit on s'intéresse a des changements macroscopiques, a long terme, pas a la milliseconde.

c'est probablement moins nocif que le HFT, mais est-ce pour autant bien ?

La finance a bon dos, mais peut être que si les gouvernements et les gens comme toi et moi arrêtaient de vivre a crédit on ne serait pas autant dans la merde.

ouais, c'est sûr. Mais il ne faudrait pas non plus croire que la finance se résume à la bourse. Dans le vaste de monde de la finance, il y a des trucs utiles, et d'autres moins.

je ne risquerais jamais mon argent pour investir dans des startups, ou dans des bons du trésor Grec. Il y a des gens qui prennent ces risques, et il est normal qu'ils soient payes en retour, non ?

Je ne sais pas si on peut répondre à cette question sans regarder le type de société qu'on veut au niveau macroscopique. Dans la société actuelle, c'est effectivement comme ça que ça marche, donc c'est "normal". Est-ce pour autant la meilleure façon de financer les entreprises ?

Pour les états, le financement ne devrait pas passer par le bon vouloir des investisseurs. Un état a les moyens de définir ses recettes comme ses dépenses. Le fait est que le verrouillage du système politique nous enferme dans du clientélisme (local ou de classe). D'autre part, il ne me semble pas que les investisseurs privés se soient rués au secours de la Grèce. J'ai même cru comprendre que c'était plutôt le contraire, et que c'est les autres états européens qui ont sorti du pognon, avec beaucoup de réticence et après beaucoup d’atermoiements.

La bourse ne sert pas qu'a enrichir les grands patrons, elle sert aussi a financer des vrais projets.

D'après Frédéric Lordon, ça a été vrai à un moment, mais ça ne l'est plus. Malheureusement, l'article de départ n'est pas accessible publiquement, mais il y a quand même cette interview

http://blog.mondediplo.net/2010-03-12-Il-faut-fermer-la-Bourse

la recherche de Thunderbird me convient très bien, mais je reçois un volume d'e-mail très raisonnable. J'avais vu la conf sur mailpile au fosdem, et ça a l'air très très chouette. Je ne sais pas si c'est utilisable en prod mais c'est un projet à suivre.

Note que tu invoques sed une fois de trop, tu peux écrire

sed "1d; s/ .*//"

ça n'a l'air de rien, mais sur des gros volumes de données, la différence en performance peut-être significative

hmmm … alors j'avais mal compris ta question … et je pensais que t'avais testé la version avec cut :D

cut utilise aussi les délimiteurs dans la sortie, donc, pas besoin de les remettre, ils y sont déjà.

chaîne de recherche awk

Certes, mais il y avait aussi du sed dans la question, alors du coup … ;-)
non, en vrai, il y a deux raisons :

• le demandeur ajoute parfois une contrainte technologique par ignorance des alternatives plutôt que par choix délibéré de la techno vraiment adaptée à son problème,
• je ne suis pas super fan de awk, et je crois qu'on peut le remplacer par quelque chose de "mieux" (souvent sed) dans quasiment tous les cas.

avec cut, tu peux "reecrire" la chaine pour obtenir /1/2 en sortie ?

j'imagine que tu pensais /2/1 ?
Si c'est bien le cas, la réponse est, à ma connaissance, non, mais il se trouve que ce n'était pas la question ! ;-)
Pour extraire des champs sans réordonner -> cut, pour des trucs hors périmètre de cut -> autre chose

cut permet aussi de spécifier le délimiteur de champs:

cut -d '/' -f 1,3

ça me rappelle quelque chose . Eet-ce qu'il aurait pas un GPS dans son alim ce brave homme ?

Quel genre de portabilité ? C++ est très portable.

ça dépend. Si tu n'utilises toujours le même compilo sur toutes les plate formes, ça ira. Par contre, si tu utilises le compilo de Sun sur Solaris, le compilo d'HP sur HP-UX, g++ sur Linux, etc … il vaut mieux ne pas utiliser les fonctionnalités trop récentes, parce qu'elles risquent de n'être supportées que par g++.

En quoi c'est pénible ? Il y a des bibliothèques qui font la conversion des noms de symboles pour toi.

je ne parlais pas de l'interprétation des symboles manglés pour qu'ils soient lisibles par un humain (nm -C !!) mais des problèmes d'intégration au runtime.
Le mangling n'étant pas standardisé, chaque compilo utilise le sien propre. Il n'est pas imaginable de linker deux libs binaires produites par deux compilos différents. Si tu compiles tout toi même, pas de problème. Par contre, si tu link sur des libraires externes, en plus de la version de la lib, tu dois gérer un paramètre de dépendance supplémentaire. Eventuellement, si tu récupères une lib binaire dont tu n'as pas les sources, tu te retrouves contraint à l'utilisation du compilateur qui a servi à générer cette lib.
Pire, deux versions différentes d'une même suite de compilation peuvent être incompatibles entre elles (c'est le cas de g++, qui pète régulièrement la compatibilité du mangling).
Côté mise en prod, ça peut aussi être un joyeux boxon. Pour peu que l'infrastructure technique ne soient pas complètement bien contrôlée, et que plusieurs services interviennent …

tu peux toujours utiliser extern "C" pour exporter une interface plus « simple ».

oui, tu peux (en fait t'as pas le choix), mais c'est particulièrement pas objet, et ça tire son lot de contrainte. Tu ne peux pas exposer n'importe quoi via des extern "C", et ça peut demander parfois pas mal de contorsions pour arriver à un truc qui marche.

Ensuite, Python et Java étant des langage objets eux aussi, c'est plus facile de mapper le concept d'objet d'un langage vers l'autre en C++ qu'en C.

Alors là, je demande à voir. Tu vas faire du extern "C" de toute façon.

Le C++ c'est trop difficile à apprendre

"Le C++ est difficile à apprendre" n'est pas un bon argument. Par contre, "le C++ est trop difficile à apprendre", ça se discute. Pour le reformuler, la question est de savoir si le temps que tu vas investir à maîtriser les subtilités du C++ va payer. C'est impossible à mesurer à priori, on ne peut que s'appuyer sur son intuition et ce qu'on peut lire sur le sujet. Si j'avais du faire autre chose que du C il y a 10 ans, j'aurais sûrement fait du C++. Mais aujourd'hui, avec la pléthore de langage qui bénéficie de l'expérience du C++, et notamment des endroits ou le langage s'est un peu fourvoyé, j'aurais pas du tout envie de rentrer dans la complexité C++ (Avis personnel, chacun en pense ce qu'il veut).

Pareil pour le C.

pas tout à fait. Même en écrivant du C++ "non-C" (pas de gestion de mémoire manuelle, utilisation des exceptions et tout ce qu'il faut), il y a plus de fonctionnalités dans C++, et la combinatoire pour mal les utiliser est plus élevée.

Faire des cast de type à tout bout de champ par exemple.

je veux bien un exemple de code avec ce que tu considères être des "cast à tout bout de champs", parce que ça ne me parait pas être une fatalité.

Je ne dis pas que le C est supérieur au C++ (ça serait crétin). Il est indéniable que le C++ permet, pour ceux qui le maîtrisent, de développer beaucoup plus vite qu'en C. Il y a même des situations ou du code en C++ tourne plus vite que du C. Mais le C++ est un langage exigeant. La migration du C au C++ n'est pas indolore, voire coûteuse. Faut voir si ça vaut le coup ou pas. Je ne dis pas autre chose (même s'il m'a fallu plein de mots pour en arriver là).