De façon minimaliste, oui. C'est avec des machines à états (mais pas uniquement) que l'on implémente des parseurs à expressions rationnelles. Mais là, c'est un peu plus "complet" ;)
S'il est vrai que l'on ne croise pas beaucoup d'automates (machine à état) dans le monde du "gros" logiciel, en revanche, c'est très utilisé en électronique.
Pour le boulot j'ai réalisé un projet (service de traitement d'images) avec au départ un nombre limité de fonctionnalité. Face au résultat encourageant, on m'a vite demandé d'ajouter telle ou telle fonctionnalités dont certaines sortaient largement du cadre de départ. J'ai vite compris qu'il me faudrait un moyen de gérer des ajouts/exceptions fonctionnels importants si je ne voulais pas tout re-coder (ou presque) à chaque fois.
Pour la v2, j'ai choisi de coder ma propre VFSM (machine à état fini virtuel) et de lui déléguer toute l'intelligence fonctionnelle. En dehors des avantages "techniques" à utiliser des automates, ça m'a aussi permis de pouvoir m'adapter très vite au changement SANS générer de complexité, puisque seul la description formelle de l'automate change.
Aujourd'hui je me demande encore pourquoi je n'ai pas utilisé d'automate plus souvent :)
L'accès à la démo n'est pas immédiat. Il faut encore s'inscrire (seul le mail est exigé) pour recevoir un couple login/mdp.
Je suis fatigué de devoir m'inscrire à tout bout de champ, de devoir donner mon email à des personnes que je ne connais pas… Je sais bien qu'il existe des sites pour créer des emails temporaires, mais là, ma curiosité a été coupée dans son élan… Dommage.
Pour l'adoption massive d'un nouveau langage, la richesse de la bibliothèque standard est cruciale. C'est peut-être là où l'on sent que c'est la première version du langage. La richesse fonctionnelle mérite de s'étoffer. Pour une fonctionnalité aussi courante que l'analyse des arguments de la ligne de commande, je suis resté sur ma faim. C'est le package « flag » qui s'occupe de ça. On atteint vite ses limites : impossible de passer plusieurs fois la même option. Impossible de concaténer les options courtes (cmd -t -u ==> cmd -tu). Le parser ne trouve plus rien (et ne prévient pas) si le premier argument ne débute pas par un tiret…
Le langage est jeune, certes, mais c'est important de proposer une bonne bibliothèque (au moins sur les fonctionnalités basiques) si Go veut se placer d'entrée de jeu comme langage généraliste.
Je ne suis pas fan de certaines subtilités. Par exemple les tableaux, passés par valeur alors que les slices le sont par référence. En revanche, j'apprécie de pouvoir retourner plusieurs éléments lors d'un return.
Personnellement j'aime assez Go. Le fait qu'il soit compilé implique - a priori - de bonnes performances d'exécution. Reste à évaluer le poids du runtime sur celles-ci.
Et vous qui vous initiez aussi, vous en pensez quoi ? (PS: Mon background: C et Python)
J'utilise PostgreSQL depuis 1995 (son nom était alors postgres95) sous Linux. À cette époque, les clés primaires n'étaient pas encore natives…
Un jour, bien plus tard et quelques versions de PG après, j'ai entendu parlé de MySQL. Certain en ont dit que c'était un vrai SGBDR et d'autres disaient que c'était juste une couche SQL au-dessus de fichiers plats (en référence à MyISAM j'imagine).
Par chance, j'ai appris le SQL et le modèle entité-relation avant MySQL. Après avoir regardé MySQL de plus près, je me suis fait MON avis et lui prédisait seulement un succès d'estime.
Mais voilà, j'ai été trop "scientifique" dans ma comparaison. MySQL était fonctionnellement en retrait comparé à PostgreSQL (c'est toujours le cas). Mais c'était sans compter sur un acteur majeur: Windows. En effet je pense que c'est grâce à lui que MySQL a acquis la popularité qu'on lui connait aujourd'hui. Pourquoi ? Pour une raison très simple: MySQL s'installe facilement sous Windows contrairement à PG. Il a fallu attendre la version 8 de PG avant d'avoir un installeur natif. Et encore, certaines limitations intrinsèques de Windows en limitaient PG. Les hébergeurs ont suivi la demande, amplifiant encore le phénomène.
Windows était (et l'est toujours) une plateforme très populaire. MySQL est monté sur son dos le premier. Il n'a trouvé aucun concurrent dans sa catégorie. De quoi séduire une quantité astronomique de développeurs de tout poil, sans expérience avec un SGBDR digne de ce nom. MySQL s'est alors répandu comme une traîné de poudre en dépit de sa médiocrité, aidé par d'autres vecteurs tels que PHP et l'apparition d’installeurs tout-en-un type WAMP et consorts. Je pense donc qu'il ne faut pas chercher sa popularité dans d’hypothétiques qualités techniques. Mc Donald est aussi très populaire, est-ce pour la qualité gastronomique de ses produits ?
En conclusion, l'habit fait donc le moine ;-) Moralité, en ces temps électoraux, mieux vaut un bon spin doctor qu'un bon programme pour être populaire et gagner des voix ;-)
Voilà un truc que j'ai du mal à comprendre. A croire que hors MySQL il n'existe pas d'autre SGBD. C'est comme microsoft qui voudrait que hors IE il n'y ait pas d'autres navigateurs.
Si la bataille du navigateur est perdue pour microsoft grâce à la diversité et la qualité des autres navigateurs, quand arriverons nous à en finir avec ces insupportable menottes qui lient et limitent tant de logiciels à MySQL ?
Messieurs les développeurs, il existe autres choses (heureusement) que MySQL. Pensez donc à faire une couche d'indépendance et votre CMS sortira du lot. Pour ma part, il est éliminé d'office de ma sélection puisque qu'il me retire le choix de ma base de données. Dommage. Typo3, EZ Publish, Drupal & Co ont encore de beaux jours devant eux :-)
Ha bah si moi je comprend qu'il faut être payé pour développer un outil qui sert pas à grand chose sur un GNU/Linux. Quel développeur Linux voudrait perdre son temps à réinventer une roue hexagonale ?
Même si mes enfants en sont encore au niveau d'un logiciel comme "Gcompris", je suis très heureux de découvrir qu'une fois au lycée ils pourront utiliser un ordinateur de la maison; sous GNU/Linux. Pas facile quand des professeurs exigent de rendre un travail rédigé exclusivement sous Word!!
Grâce à de biens belles initiatives comme Pymecavideo, la liberté de choix est rendu. Merci et bravo.
Il faudrait commencer par éduquer les développeurs. Se sont eux qui font le choix malheureux de souder une application (de grande audience) à une base de données unique.
Rappelons nous le temps ou les sites WEB étaient tous fait pour le seul navigateur IE.
Les développeurs devrait éviter de faire la même erreur avec les BDD.
Si coté WEB on s'en ai globalement sorti, il est probablement impossible d'en faire autant avec SQL qui, pourtant, est lui aussi un standard en théorie. D'ailleurs il n'y a pas que SQL pour stocker des données. Même en se limitant à SQL, de nombreuses applications sont en mesures d'utiliser indifféremment telle ou telle BDD. Elle sont conçus sur une couche d'abstraction d'accès aux données. Et ceci devrait être la règle chez les développeurs d'applications se destinant à un grand nombre d'utilisateurs.
finalement la disparition de MySQL serait un mal pour un bien si cela permettait aux développeurs de prendre conscience des erreurs commises.
Oui, et surtout grâce à une disponibilité précoce pour la plate-forme Windows. Voilà le secret de popularité de MySQL. Rien de plus, rien de moins. Et oui, MySQL doit tout (en terme de popularité) à Windows... car à cette époque les autres BDD libres était "compliquées" à installer sur un OS ou la qualité d'un produit se mesure à sa faciliter d'installation (sic).
Les hébergeurs ont suivi la demande des clients. Si la demande va vers PostgreSQL, il suivront encore, n'en doute pas, c'est même déjà le cas.
Même chose pour tout logiciels assez mal fichu pour penser qu'il n'existe qu'un SGBD; il suivra et utilisera peut-être enfin une bonne méthode de développement: couche d'abstraction aux données.
Tu peux utiliser le navigateur de ton choix pour voir cette page. Pourquoi cela ne devrait-il pas être aussi évident pour l'accès aux données ? La plupart des applications que je connaisse exigeant exclusivement MySQL (nombre de CMS) est bâti sur cette absence de méthode. La déferlante MVC a au moins le mérite de remettre en lumière les articulations entre couches logiciels.
MySQL est très populaire, certes. Pour autant il n'est pas le seul SGBDR libre et de loin. La licence GPL ne le "protège" pas puisque l'inquiétude est très grande sur son avenir. Est-ce parce que le développement de MySQL est porté par une société commerciale plutôt que par une communauté ?. Je ne saurais y répondre.
En comparaison PostgreSQL s'appuie sur une communauté et une licence BSD. Finalement ce modèle semble offrir une plus grande solidité face au risque d'une prise de contrôle par une entreprise aux objectifs incertains. Et cela même avec une licence plus permissive. In fine ce modèle semble pérenniser un moteur qui, aujourd'hui, concurrence Oracle sur de nombreux projets d'envergure. Preuve de qualité.
Le choix reste possible. Je crois que la peur d'une disparition potentielle de MySQL résulte de la perspective d'adaptation (au sens Darwinien) nécessaire. Le danger qui pèse éventuellement sur MySQL ne pèse pas sur l'écosystème du libre. N'est-ce pas cela le plus important ?
MySQL est très populaire, certes. Pour autant il n'est pas le seul SGBDR libre et de loin. La licence GPL ne le "protège" pas puisque l'inquiétude est très grande sur son avenir. Est-ce parce que le développement de MySQL est porté par une société commerciale plutôt que par une communauté ?. Je ne saurais y répondre.
En comparaison PostgreSQL s'appuie sur une communauté et une licence BSD. Finalement ce modèle semble offrir une plus grande solidité face au risque d'une prise de contrôle par une entreprise aux objectifs incertains. Et cela même avec une licence plus permissive. In fine ce modèle semble pérenniser un moteur qui, aujourd'hui, concurrence Oracle sur de nombreux projets d'envergure. Preuve de qualité.
Le choix reste possible. Je crois que la peur d'une disparition potentielle de MySQL résulte de la perspective d'adaptation (au sens Darwinien) nécessaire. Le danger qui pèse éventuellement sur MySQL ne pèse pas sur l'écosystème du libre. N'est-ce pas cela le plus important ?
"QT n'est pas qu'un toolkit graphique mais aussi un framework C++ complet"Bien, maintenant si tu pense que ton argument suffit tu n'auras aucune difficulté à me le démontrer. Tiens, trouves mois trois ou quartes exemples de programme en ligne de commande utilisant qt-core pour faire de la copie de fichier... et je serais convaincu. Pourquoi pas eclipse aussi, en pilotant la fonction Open/Rename/Save AS, on doit pouvoir faire un super copieur de fichier avec ce framework!
(...)utiliser QT pour tout ce qui est gestion des évènements, librairies I/O, et toutes les joyeusetés qui prennent 2 ans à faire marcher sous windows quand on est un dev Unix.Tu vois, on en revient au sujet du fil: "Surtout utile pour Windows".
tout est fait en signal/slot qui oblige d'utilisé Qt
C'est le couplage fort dont je parlais == erreur de conception == mauvaise méthode de développement
car avoir un outils en ligne de commande dépendant de Qt (juste le coeur) est assez dommage
Je doit manquer de clarté. Ou alors il vous manque quelques fondamentaux en matière de développement. A l'évidence vous n'avez rien compris, une bibliothèque de fonction n'a naturellement pas de dépendance avec un toolkit graphique. Bien sur qu'il faut refaire le mur s'il dépend d'un bout de bois pour tenir debout! Regardez le concept MVC [http://fr.wikipedia.org/wiki/Mod%C3%A8le-Vue-Contr%C3%B4leur] par exemple.
En effet il faut distinguer les types d'usage et bien les considérer.
o Il y a l'utilisateur occasionnel d'un outil graphique
o et "l'informaticien" qui veut automatiser un processus.
J'essaie de faire comprendre que ces deux types d'usage ne sont pas incompatibles. Il suffit juste d'une bonne conception au départ; consistant ici à ne pas fortement coupler l'IHM et la fonction. Pourquoi ne pas écrire une bibliothèque (libUltraCopier) ? Elle pourrait ainsi être liée, au choix, à un outil en ligne de commande ou de type 100% IHM "pas prise de tête (!)". Mieux, elle pourrait même être utilisée dans des situations que l'auteur n'a pas imaginé... Quoi de plus valorisant de plus ?
Attention, je n'oppose pas IHM contre ligne de commande, ce serait complètement idiot. Je pense simplement qu'il est plus judicieux que l'IHM s'appuie sur un outil accessible en ligne de commande lorsque celui-ci existe. C'est totalement équivalent pour MMe Michu qui ne s'intéresse pas à ce qui se passe sous le clavier.
En revanche ça laisse toute latitude à celui qui veut faire de l'informatique et outiller ses processus.
UltraCopier pourrait parfaitement être un outil en ligne de commande accompagné d'un frontend graphique multi-plateforme comme il en existe déjà. De sorte on conserve le meilleur des deux mondes et tout le monde est content.
Utilisateur d'Ubuntu j'utilise Synaptic régulièrement sur mon desktop. Pour autant je ne pourrais pas me passer de la commande apt-get & Co.
Ce que j'aime avec ce principe c'est que je peux adapter le système à mes besoins. Alors que sous Windows c'est à moi de m'adapter au système et ses limitations. C'est peut-être purement conceptuelle, mais je crois pourtant que c'est une différence fondamentale entre la vision de l'ouvert (la réutilisation par tous) et du fermé (rendre captif).
Nous sommes sur linuxfr. C'est quoi un utilisateur "standard" de GNU/Linux ? Un utilisateur qui veut faire comme sur Windows ? Ca signifie pour lui qu'il passe à coté de tout ce qui fait la différence et la puissance de son système GNU/Linux. M'est d'avis que cet utilisateur là profite plus à Microsoft/Apple qu'au monde du libre.
cygwin est installé sur tous les WinXP de mon entreprise. Difficile d'imaginer le plaisir que ça procure de faire un ssh sur un XP et se retrouver sous bash . Puis de là pouvoir administrer quantité de chose... automatiquement. C'est, par exemple, de cette façon que je déploie des logiciels sous Windows.
Sous Windows je peux comprendre l'intérêt de ce type d'outil; la ligne de commande est très pauvre. En revanche sur *nix (dont Mac OSX) la ligne de commande propose des outils très efficaces. Il suffit de lire le manuel de la commande rsync, par exemple, pour s'en convaincre (vitesse de copie réglable, vérification automatique par somme de contrôle md5, copie de machine à machine... ). Quand une interface graphique est nécessaire, je préfère qu'elle s'appuie sur les outils en ligne de commande. C'est plus dans la philosophie unix: on fait qu'une chose à la fois, mais on le fait bien.
Même si UltraCopier peut s'utiliser en ligne de commande, il reste dépendant de bibliothèques graphiques, ce qui sur un serveur peut devenir rédhibitoire. S'il ne peut s'utiliser partout alors il faudra apprendre à utiliser un outre outil... Autant connaître le plus universel. Du coup, dans un environnement graphique, je préfère une approche comme celle de grsync (http://www.opbyte.it/grsyn). L'interface graphique est séparée de l'outil. Pas besoin de réinventer la roue une énième fois.
[^] # Re: exemple en C
Posté par katov . En réponse à la dépêche Pourquoi les développeurs n'utilisent pas plus de machines à état ?. Évalué à 1.
De façon minimaliste, oui. C'est avec des machines à états (mais pas uniquement) que l'on implémente des parseurs à expressions rationnelles. Mais là, c'est un peu plus "complet" ;)
# VFSM
Posté par katov . En réponse à la dépêche Pourquoi les développeurs n'utilisent pas plus de machines à état ?. Évalué à 1.
S'il est vrai que l'on ne croise pas beaucoup d'automates (machine à état) dans le monde du "gros" logiciel, en revanche, c'est très utilisé en électronique.
Pour le boulot j'ai réalisé un projet (service de traitement d'images) avec au départ un nombre limité de fonctionnalité. Face au résultat encourageant, on m'a vite demandé d'ajouter telle ou telle fonctionnalités dont certaines sortaient largement du cadre de départ. J'ai vite compris qu'il me faudrait un moyen de gérer des ajouts/exceptions fonctionnels importants si je ne voulais pas tout re-coder (ou presque) à chaque fois.
Pour la v2, j'ai choisi de coder ma propre VFSM (machine à état fini virtuel) et de lui déléguer toute l'intelligence fonctionnelle. En dehors des avantages "techniques" à utiliser des automates, ça m'a aussi permis de pouvoir m'adapter très vite au changement SANS générer de complexité, puisque seul la description formelle de l'automate change.
Aujourd'hui je me demande encore pourquoi je n'ai pas utilisé d'automate plus souvent :)
# Pas de mail = pas de démo
Posté par katov . En réponse à la dépêche Sortie de Maarch Entreprise 1.3. Évalué à 6. Dernière modification le 19 mai 2012 à 14:52.
L'accès à la démo n'est pas immédiat. Il faut encore s'inscrire (seul le mail est exigé) pour recevoir un couple login/mdp.
Je suis fatigué de devoir m'inscrire à tout bout de champ, de devoir donner mon email à des personnes que je ne connais pas… Je sais bien qu'il existe des sites pour créer des emails temporaires, mais là, ma curiosité a été coupée dans son élan… Dommage.
# Découverte
Posté par katov . En réponse à la dépêche Sortie d'une première version stable de Go. Évalué à 10.
Pour l'adoption massive d'un nouveau langage, la richesse de la bibliothèque standard est cruciale. C'est peut-être là où l'on sent que c'est la première version du langage. La richesse fonctionnelle mérite de s'étoffer. Pour une fonctionnalité aussi courante que l'analyse des arguments de la ligne de commande, je suis resté sur ma faim. C'est le package « flag » qui s'occupe de ça. On atteint vite ses limites : impossible de passer plusieurs fois la même option. Impossible de concaténer les options courtes (cmd -t -u ==> cmd -tu). Le parser ne trouve plus rien (et ne prévient pas) si le premier argument ne débute pas par un tiret…
Le langage est jeune, certes, mais c'est important de proposer une bonne bibliothèque (au moins sur les fonctionnalités basiques) si Go veut se placer d'entrée de jeu comme langage généraliste.
Je ne suis pas fan de certaines subtilités. Par exemple les tableaux, passés par valeur alors que les slices le sont par référence. En revanche, j'apprécie de pouvoir retourner plusieurs éléments lors d'un return.
Personnellement j'aime assez Go. Le fait qu'il soit compilé implique - a priori - de bonnes performances d'exécution. Reste à évaluer le poids du runtime sur celles-ci.
Et vous qui vous initiez aussi, vous en pensez quoi ? (PS: Mon background: C et Python)
[^] # Re: Quitte à rester dans le gore
Posté par katov . En réponse au journal MySQL est une bouse immonde. Évalué à 1.
J'utilise PostgreSQL depuis 1995 (son nom était alors postgres95) sous Linux. À cette époque, les clés primaires n'étaient pas encore natives…
Un jour, bien plus tard et quelques versions de PG après, j'ai entendu parlé de MySQL. Certain en ont dit que c'était un vrai SGBDR et d'autres disaient que c'était juste une couche SQL au-dessus de fichiers plats (en référence à MyISAM j'imagine).
Par chance, j'ai appris le SQL et le modèle entité-relation avant MySQL. Après avoir regardé MySQL de plus près, je me suis fait MON avis et lui prédisait seulement un succès d'estime.
Mais voilà, j'ai été trop "scientifique" dans ma comparaison. MySQL était fonctionnellement en retrait comparé à PostgreSQL (c'est toujours le cas). Mais c'était sans compter sur un acteur majeur: Windows. En effet je pense que c'est grâce à lui que MySQL a acquis la popularité qu'on lui connait aujourd'hui. Pourquoi ? Pour une raison très simple: MySQL s'installe facilement sous Windows contrairement à PG. Il a fallu attendre la version 8 de PG avant d'avoir un installeur natif. Et encore, certaines limitations intrinsèques de Windows en limitaient PG. Les hébergeurs ont suivi la demande, amplifiant encore le phénomène.
Windows était (et l'est toujours) une plateforme très populaire. MySQL est monté sur son dos le premier. Il n'a trouvé aucun concurrent dans sa catégorie. De quoi séduire une quantité astronomique de développeurs de tout poil, sans expérience avec un SGBDR digne de ce nom. MySQL s'est alors répandu comme une traîné de poudre en dépit de sa médiocrité, aidé par d'autres vecteurs tels que PHP et l'apparition d’installeurs tout-en-un type WAMP et consorts. Je pense donc qu'il ne faut pas chercher sa popularité dans d’hypothétiques qualités techniques. Mc Donald est aussi très populaire, est-ce pour la qualité gastronomique de ses produits ?
En conclusion, l'habit fait donc le moine ;-) Moralité, en ces temps électoraux, mieux vaut un bon spin doctor qu'un bon programme pour être populaire et gagner des voix ;-)
[^] # Re: Les sources ???
Posté par katov . En réponse à la dépêche Sortie de Ultracopier 0.3 pour Noël. Évalué à 2.
Tu as fait ça dans quelle école ?
# MySQL, encore un non choix
Posté par katov . En réponse à la dépêche glFusion, un CMS qu'il est bien.... Évalué à 2.
Si la bataille du navigateur est perdue pour microsoft grâce à la diversité et la qualité des autres navigateurs, quand arriverons nous à en finir avec ces insupportable menottes qui lient et limitent tant de logiciels à MySQL ?
Messieurs les développeurs, il existe autres choses (heureusement) que MySQL. Pensez donc à faire une couche d'indépendance et votre CMS sortira du lot. Pour ma part, il est éliminé d'office de ma sélection puisque qu'il me retire le choix de ma base de données. Dommage. Typo3, EZ Publish, Drupal & Co ont encore de beaux jours devant eux :-)
[^] # Re: ...
Posté par katov . En réponse à la dépêche Sortie de la version finale d'ultracopier. Évalué à 2.
# Bravo
Posté par katov . En réponse à la dépêche Pymecavideo sort en version 4 et est compatible baccalauréat. Évalué à 4.
Grâce à de biens belles initiatives comme Pymecavideo, la liberté de choix est rendu. Merci et bravo.
[^] # Re: MySQL est utilisé par d'aures logiciels libres !
Posté par katov . En réponse à la dépêche Sauvons MySQL !. Évalué à 4.
Rappelons nous le temps ou les sites WEB étaient tous fait pour le seul navigateur IE.
Les développeurs devrait éviter de faire la même erreur avec les BDD.
Si coté WEB on s'en ai globalement sorti, il est probablement impossible d'en faire autant avec SQL qui, pourtant, est lui aussi un standard en théorie. D'ailleurs il n'y a pas que SQL pour stocker des données. Même en se limitant à SQL, de nombreuses applications sont en mesures d'utiliser indifféremment telle ou telle BDD. Elle sont conçus sur une couche d'abstraction d'accès aux données. Et ceci devrait être la règle chez les développeurs d'applications se destinant à un grand nombre d'utilisateurs.
finalement la disparition de MySQL serait un mal pour un bien si cela permettait aux développeurs de prendre conscience des erreurs commises.
[^] # Re: Ce n'est pas une bataille du libre
Posté par katov . En réponse à la dépêche Sauvons MySQL !. Évalué à 6.
Oui, et surtout grâce à une disponibilité précoce pour la plate-forme Windows. Voilà le secret de popularité de MySQL. Rien de plus, rien de moins. Et oui, MySQL doit tout (en terme de popularité) à Windows... car à cette époque les autres BDD libres était "compliquées" à installer sur un OS ou la qualité d'un produit se mesure à sa faciliter d'installation (sic).
[^] # Re: Ce n'est pas une bataille du libre
Posté par katov . En réponse à la dépêche Sauvons MySQL !. Évalué à 3.
Même chose pour tout logiciels assez mal fichu pour penser qu'il n'existe qu'un SGBD; il suivra et utilisera peut-être enfin une bonne méthode de développement: couche d'abstraction aux données.
Tu peux utiliser le navigateur de ton choix pour voir cette page. Pourquoi cela ne devrait-il pas être aussi évident pour l'accès aux données ? La plupart des applications que je connaisse exigeant exclusivement MySQL (nombre de CMS) est bâti sur cette absence de méthode. La déferlante MVC a au moins le mérite de remettre en lumière les articulations entre couches logiciels.
[^] # Re: La fin de MySQL n'est pas la fin du SGBDR libre
Posté par katov . En réponse à la dépêche Sauvons MySQL !. Évalué à 10.
# La fin de MySQL n'est pas la fin du SGBDR libre
Posté par katov . En réponse à la dépêche Sauvons MySQL !. Évalué à 2.
En comparaison PostgreSQL s'appuie sur une communauté et une licence BSD. Finalement ce modèle semble offrir une plus grande solidité face au risque d'une prise de contrôle par une entreprise aux objectifs incertains. Et cela même avec une licence plus permissive. In fine ce modèle semble pérenniser un moteur qui, aujourd'hui, concurrence Oracle sur de nombreux projets d'envergure. Preuve de qualité.
Le choix reste possible. Je crois que la peur d'une disparition potentielle de MySQL résulte de la perspective d'adaptation (au sens Darwinien) nécessaire. Le danger qui pèse éventuellement sur MySQL ne pèse pas sur l'écosystème du libre. N'est-ce pas cela le plus important ?
# La fin de MySQL n'est pas la fin du SGBDR libre
Posté par katov . En réponse à la dépêche Sauvons MySQL !. Évalué à 10.
En comparaison PostgreSQL s'appuie sur une communauté et une licence BSD. Finalement ce modèle semble offrir une plus grande solidité face au risque d'une prise de contrôle par une entreprise aux objectifs incertains. Et cela même avec une licence plus permissive. In fine ce modèle semble pérenniser un moteur qui, aujourd'hui, concurrence Oracle sur de nombreux projets d'envergure. Preuve de qualité.
Le choix reste possible. Je crois que la peur d'une disparition potentielle de MySQL résulte de la perspective d'adaptation (au sens Darwinien) nécessaire. Le danger qui pèse éventuellement sur MySQL ne pèse pas sur l'écosystème du libre. N'est-ce pas cela le plus important ?
[^] # Re: Surtout utile pour Windows
Posté par katov . En réponse à la dépêche Sortie d'UltraCopier 0.2 et Catchcopy. Évalué à -2.
"QT n'est pas qu'un toolkit graphique mais aussi un framework C++ complet"Bien, maintenant si tu pense que ton argument suffit tu n'auras aucune difficulté à me le démontrer. Tiens, trouves mois trois ou quartes exemples de programme en ligne de commande utilisant qt-core pour faire de la copie de fichier... et je serais convaincu. Pourquoi pas eclipse aussi, en pilotant la fonction Open/Rename/Save AS, on doit pouvoir faire un super copieur de fichier avec ce framework!(...)utiliser QT pour tout ce qui est gestion des évènements, librairies I/O, et toutes les joyeusetés qui prennent 2 ans à faire marcher sous windows quand on est un dev Unix.Tu vois, on en revient au sujet du fil: "Surtout utile pour Windows".[^] # Re: Surtout utile pour Windows
Posté par katov . En réponse à la dépêche Sortie d'UltraCopier 0.2 et Catchcopy. Évalué à -2.
tout est fait en signal/slot qui oblige d'utilisé QtC'est le couplage fort dont je parlais == erreur de conception == mauvaise méthode de développement
car avoir un outils en ligne de commande dépendant de Qt (juste le coeur) est assez dommageJe doit manquer de clarté. Ou alors il vous manque quelques fondamentaux en matière de développement. A l'évidence vous n'avez rien compris, une bibliothèque de fonction n'a naturellement pas de dépendance avec un toolkit graphique. Bien sur qu'il faut refaire le mur s'il dépend d'un bout de bois pour tenir debout! Regardez le concept MVC [http://fr.wikipedia.org/wiki/Mod%C3%A8le-Vue-Contr%C3%B4leur] par exemple.
[^] # Re: Surtout utile pour Windows
Posté par katov . En réponse à la dépêche Sortie d'UltraCopier 0.2 et Catchcopy. Évalué à 2.
o Il y a l'utilisateur occasionnel d'un outil graphique
o et "l'informaticien" qui veut automatiser un processus.
J'essaie de faire comprendre que ces deux types d'usage ne sont pas incompatibles. Il suffit juste d'une bonne conception au départ; consistant ici à ne pas fortement coupler l'IHM et la fonction. Pourquoi ne pas écrire une bibliothèque (libUltraCopier) ? Elle pourrait ainsi être liée, au choix, à un outil en ligne de commande ou de type 100% IHM "pas prise de tête (!)". Mieux, elle pourrait même être utilisée dans des situations que l'auteur n'a pas imaginé... Quoi de plus valorisant de plus ?
[^] # Re: Surtout utile pour Windows
Posté par katov . En réponse à la dépêche Sortie d'UltraCopier 0.2 et Catchcopy. Évalué à 10.
En revanche ça laisse toute latitude à celui qui veut faire de l'informatique et outiller ses processus.
UltraCopier pourrait parfaitement être un outil en ligne de commande accompagné d'un frontend graphique multi-plateforme comme il en existe déjà. De sorte on conserve le meilleur des deux mondes et tout le monde est content.
Utilisateur d'Ubuntu j'utilise Synaptic régulièrement sur mon desktop. Pour autant je ne pourrais pas me passer de la commande apt-get & Co.
Ce que j'aime avec ce principe c'est que je peux adapter le système à mes besoins. Alors que sous Windows c'est à moi de m'adapter au système et ses limitations. C'est peut-être purement conceptuelle, mais je crois pourtant que c'est une différence fondamentale entre la vision de l'ouvert (la réutilisation par tous) et du fermé (rendre captif).
[^] # Re: Surtout utile pour Windows
Posté par katov . En réponse à la dépêche Sortie d'UltraCopier 0.2 et Catchcopy. Évalué à -4.
cygwin est installé sur tous les WinXP de mon entreprise. Difficile d'imaginer le plaisir que ça procure de faire un ssh sur un XP et se retrouver sous bash . Puis de là pouvoir administrer quantité de chose... automatiquement. C'est, par exemple, de cette façon que je déploie des logiciels sous Windows.
# Surtout utile pour Windows
Posté par katov . En réponse à la dépêche Sortie d'UltraCopier 0.2 et Catchcopy. Évalué à 3.
Même si UltraCopier peut s'utiliser en ligne de commande, il reste dépendant de bibliothèques graphiques, ce qui sur un serveur peut devenir rédhibitoire. S'il ne peut s'utiliser partout alors il faudra apprendre à utiliser un outre outil... Autant connaître le plus universel. Du coup, dans un environnement graphique, je préfère une approche comme celle de grsync (http://www.opbyte.it/grsyn). L'interface graphique est séparée de l'outil. Pas besoin de réinventer la roue une énième fois.