C'est peut-être le nouveau nom, mais du coup ils en ont profité pour gommer toute référence à d'autres DBMS.
Dommage car il semble vraiment bien.
Le problème c'est qu'il nous est déjà arrivé plus d'une fois de changer le DBMS de destination en cours de projet, donc utiliser des outils différents suivant le DBMS n'est même pas une bonne solution car ça supposera malgré tout de refaire tout le schéma (sauf si on a des logiciels différents avec un format d'échange commun).
On aurait plutôt besoin d'un outil multi-DBMS, sinon il va falloir changer de programme suivant le DBMS de destination, et si on change d'avis en cours de route (c'est déjà arrivé) on est bon pour refaire le schéma car je doute qu'il existe un format d'échange pour ce type de données.
Bah, laisse tomber, il est juste là pour dénigrer. S'il avait envie de faire avancer le débat il aurait proposé des exemples concrets de choses à améliorer.
C'est du troll de base.
Oui, enfin, moyennement utilisable.
Sur mon N810 il y a quand même plusieurs fenêtre de dialogues (configuration de graphique par exemple) qui sont à peu près inutilisables parce que la moitié des composants sortent de la zone d'affichage ou se chevauchent.
Je vais quand même le récupérer pour voir ce que ça vaut.
Bon, j'ai eu un peu de mal à trouver les libs qui lui manquaient, mais à coup de ldd j'ai fini par trouver et ça se lance.
L'interface en qt2 fait assez vieille mais ça fonctionne, je présenterai à mes collègues pour voir ce qu'ils en pensent.
Dommage que ce soit développé avec un langage obsolète, je vais voir si lazarus arrive à le compiler.
C'est intéressant, mais on aurait besoin d'un outil vraiment orienté édition de base de données, qui sache quels sont les types supportés par le DBMS choisi, comment créer les index...
Pour le moment j'utilise le plugin clay pour eclipse, qui n'était déjà pas libre mais avait une version gratuite (ce qui n'est plus le cas: http://www.azzurri.jp/ ), mais come dit au début certains collègues ne veulent plus utiliser eclipse.
Je vais quand même tester ta proposition (parce qu'avec dia on pourra au moins faire des belles mises en page), mais je doute que mes collègues apprécient la solution.
je n'ai effectivement pas beaucoup cherché, il était déjà tard et j'avais besoin de dormir.
De plus, le site de dbdesigner4 disait explicitement que son successeur est mysql workbench (cf http://www.fabforce.net/downloads.php ), donc je n'ai effectivement pas cherché plus dans cette direction.
Quant au fork, effectivement la 1.4 est dispo pour linux, mais elle date de 2007 et la 1.5 n'est disponible que pour windows, c'est mauvais signe :-(
Je vais quand même le récupérer pour voir ce que ça vaut.
et puis sur une machine x86-64 tu peux tres bien faire tourner des programmes 32bits
Je sais bien qu'on peut faire tourner du x86 sur un système x86_64, je le fais déjà, mais si on peut s'en passer ça évite de charger plein de bibliothèques en double.
Ah, ça a l'air plus intéressant, il ne parlent pas de postgresql, mais je vais tester ça.
Argh, c'est mal parti.
Il n'y a pas de version x86_64, et comme c'est du delphi je ne vais pas pouvoir le recompiler moi-même, en plus le paquet a des dépendances vers des vieilles libs, je vais devoir retrouver des vieux rpm de libexpat0.
D'un point de vue technique, seule les lunettes électroniques synchronisées sur le projecteur me semble correcte techniquement mais je crois que c'est pas pour demain dans un cinéma (mais chez soit, c'est plus envisageable).
Ben si, c'est exactement ça qu'il y a dans les cinémas, des lunettes actives.
Tu ne croyais quand même pas que les gens allaient voir des films et rouge et vert??
À la limite des lunettes polarisantes, mais c'est pas génial pour le confort visuel car le filtrage n'est pas parfait et il faut garder la tête bien droite.
Si ta liste de commandes est fournie par un flux RSS, pas besoin de reprogrammer une application, des lecteurs RSS il en existe plein, y compris des plasmoïdes pour le panneau de KDE.
Hum :-)
SQLite est une base de données.
La différence avec les autres plus connu est que c'est une DB embarquée et pas un serveur.
(certains, comme mysql derby ou firebird, peuvent aussi être embarqués)
En l'occurence, la méthode getMachinById() se doit de renvoyer une MachinNotFoundException, simplement parce qu'un catch(MachinNotFoundException mnfe) {...} est mille fois plus explicite qu'un if(machin !null) {...} qui lui n'impose pas de else {log.error('oulalala');}.
Tu semble considérer que ne pas trouver ton machin est une erreur.
Moi ça me semble plutôt un comportement tout à fait normal, on cherche un certain machin, si on le trouve on en fera quelque chose sinon on fera autre chose.
C'est au code appellant de savoir si ne pas trouver de machin est une erreur (le machin aurait du être là) où une situation normale.
Seule la méthode getMachinById() doit connaitre la nomenclature d'un Id
Ça c'est un autre problème, si l'ID a une nomenclature particulière et n'accepte pas n'importe quelle valeur il faut que la méthode lance une exception (genre IllegalArgumentException) si la valeur passée est invalide.
Mais si la valeur passée est acceptable, il ne faut pas lancer d'exception simplement parce qu'on ne trouve rien.
Image la classe Map qui lancerait une exception dans son get simplement parce que la clé donnée n'est pas présente dans le Map (d'autant que certaines implémentations acceptent null en valeur, et peuvent donc retourner null même si la clé est présente).
L'argument des performances pour la gestion des exceptions est fallacieux. Les exceptions ça va vite, et bien que ce soit verbeux, c'est lisible.
Lancer une exception nécessite de construire le stacktrace de l'endroit qui a lancé l'exception (souvent quelque dizaines de StackTraceElement), ça me semble quand même significativement plus lourd que de simplement retourner null (quand c'est pertinent par rapprot à la sémentique de la méthode) qui ne va allouer aucune mémoire.
Les exceptions ne sont pas là pour indiquer que le programme va partir en sucette à partir de maintenant. Elles sont là pour rendre plus clair le déroulement d'un programme.
On n'a vraisemblablement pas la même notion de clareté d'un code.
Parce que les exceptions sont là pour indiquer des situations "exceptionnelles". Ne pas trouver un objet avec un ID donné est une situation normale, pas une exception.
D'autant qu'il est beaucoup plus efficace de retourner un null et le tester au retour plutôt que de lancer des exceptions et de jouer du try{}catch(){}.
Les exceptions ne sont pas faites pour gérer le fonctionnement normal du programme, si une exception est lancée ça indique qu'il y a un problème.
(une petite recherche sur "exception flow control" donne plein de discussions sur le sujet)
Il n'y a aucun overlay sur la carte principale, c'est uniquement un rendu d'une partie des données disponibles.
D'ailleurs, si tu clique sur la croix en haut à droite tu peux choisir d'autres rendus, et il y a d'autres sites qui proposent des cartes spécialisée, comme par exemple cloudmade ( http://maps.cloudmade.com/ ) qui propose un service de routage (qui reste un peu aléatoire dans les zones incomplètes).
Un autre exemple amusant: un rendu des vitesse maximales http://maxspeed.osm.lab.rfc822.org/
La carte de la page principale est uniquement un aperçu de ce qu'on peut faire avec les données, ça leur coute déjà cher d'avoir des serveurs qui tiennent la charge avec un recalcul en permanence des images (car les données évoluent en continu).
Pour ce qui est de la reprise de flambeau par PostgreSQL, je suis d'accord avec toi, mais ce que je voulais dire, c'est que c'est l'alternative la plus proche en OpenSource... SQLite et BerkeleyDB sont certes très pratiques pour certaines utilisations très simples, mais sont quand même loin de MySQL. Du coup, même si PostgreSQL diffère pas mal de MySQL dans la philosophie, je pense que c'est la seule alternative viable.
Il y a aussi firebird http://www.firebirdsql.org/
qui était à l'origne un fork d'interbase 6 (pendant la période où il a été opensource) et qui est un vrai SGBDR.
Les dernières version rattrapent le retard en terme de fonctionnalité (avant la version 2.0 il y avait vraiment très peu de fonctions de base), le développement est bien actif mais il souffre un peu de sa communauté réduite par rapport aux poids-lourds que sont MySQL et PostgreSQL.
Chuck norris a vu le big bang. C'est quand il a proposé aux scientifiques de leur faire une démonstration qu'ils ont jugé plus raisonnable de construire le LHC.
mc de son petit nom, est un gestionnaire de fichier en mode texte. Inspiré du vénérable norton commander (du temps du DOS), c'est un excellent gestionnaire de fichiers même en session graphique car il se contrôle entièrement au clavier (même s'il supporte le pointeur pour activer les différents éléments d'interface).
À mon avis c'est un incontournable!
Non, puisque, à en croire les développeurs, la partie bureau/taskbar en était arrivé à un état difficilement maintenable et encore plus à faire évoluer.
Ça a pris (et prend encore) du temps pour atteindre un niveau de fonctionnalités équivalent mais ça permettra d'aller beaucoup plus loin dans l'avenir.
Perso je suis en btrfs, et ça marche vraiment pas mal.
Sauf que le format sur le disque du FS n'est pas encore strictement fixé (même s'il faut une très bonne raison pour qu'il change encore).
cf http://btrfs.wiki.kernel.org/index.php/FAQ
Par exemple il a changé dans le 2.6.31, qui sait lire l'ancien format mais réécrit de façon un peu différente, donc une fois utilisé avec un 2.6.>=31 ce n'est plus lisible par un précédent (à moins de le patcher avec la dernière version de btrfs, ce qui semble prévu d'après la FAQ).
[^] # Re: heu . . .
Posté par wismerhill . En réponse au message Éditeur de schéma DB. Évalué à 1.
Dommage car il semble vraiment bien.
Le problème c'est qu'il nous est déjà arrivé plus d'une fois de changer le DBMS de destination en cours de projet, donc utiliser des outils différents suivant le DBMS n'est même pas une bonne solution car ça supposera malgré tout de refaire tout le schéma (sauf si on a des logiciels différents avec un format d'échange commun).
[^] # Re: heu . . .
Posté par wismerhill . En réponse au message Éditeur de schéma DB. Évalué à 1.
[^] # Re: Krita != Gimp
Posté par wismerhill . En réponse à la dépêche KOffice 2.2 est sorti. Évalué à 8.
C'est du troll de base.
[^] # Re: Koffice & business
Posté par wismerhill . En réponse au journal Koffice 2.2 est sorti. Évalué à 1.
Sur mon N810 il y a quand même plusieurs fenêtre de dialogues (configuration de graphique par exemple) qui sont à peu près inutilisables parce que la moitié des composants sortent de la zone d'affichage ou se chevauchent.
[^] # Re: lmgtfy
Posté par wismerhill . En réponse au message Éditeur de schéma DB. Évalué à 1.
Bon, j'ai eu un peu de mal à trouver les libs qui lui manquaient, mais à coup de ldd j'ai fini par trouver et ça se lance.
L'interface en qt2 fait assez vieille mais ça fonctionne, je présenterai à mes collègues pour voir ce qu'ils en pensent.
Dommage que ce soit développé avec un langage obsolète, je vais voir si lazarus arrive à le compiler.
[^] # Re: dia
Posté par wismerhill . En réponse au message Éditeur de schéma DB. Évalué à 1.
Pour le moment j'utilise le plugin clay pour eclipse, qui n'était déjà pas libre mais avait une version gratuite (ce qui n'est plus le cas: http://www.azzurri.jp/ ), mais come dit au début certains collègues ne veulent plus utiliser eclipse.
Je vais quand même tester ta proposition (parce qu'avec dia on pourra au moins faire des belles mises en page), mais je doute que mes collègues apprécient la solution.
[^] # Re: lmgtfy
Posté par wismerhill . En réponse au message Éditeur de schéma DB. Évalué à 1.
De plus, le site de dbdesigner4 disait explicitement que son successeur est mysql workbench (cf http://www.fabforce.net/downloads.php ), donc je n'ai effectivement pas cherché plus dans cette direction.
Quant au fork, effectivement la 1.4 est dispo pour linux, mais elle date de 2007 et la 1.5 n'est disponible que pour windows, c'est mauvais signe :-(
Je vais quand même le récupérer pour voir ce que ça vaut.
et puis sur une machine x86-64 tu peux tres bien faire tourner des programmes 32bits
Je sais bien qu'on peut faire tourner du x86 sur un système x86_64, je le fais déjà, mais si on peut s'en passer ça évite de charger plein de bibliothèques en double.
[^] # Re: lmgtfy
Posté par wismerhill . En réponse au message Éditeur de schéma DB. Évalué à 2.
Argh, c'est mal parti.
Il n'y a pas de version x86_64, et comme c'est du delphi je ne vais pas pouvoir le recompiler moi-même, en plus le paquet a des dépendances vers des vieilles libs, je vais devoir retrouver des vieux rpm de libexpat0.
[^] # Re: lmgtfy
Posté par wismerhill . En réponse au message Éditeur de schéma DB. Évalué à 1.
sinon à une certaine epoque j'utilisais DbDesigner
Ah, ça a l'air plus intéressant, il ne parlent pas de postgresql, mais je vais tester ça.
(je reste ouvert à d'autres suggestions, si d'autres ont des choses à proposer)
[^] # Re: Nouveautés
Posté par wismerhill . En réponse à la dépêche Fedora 13 « Goddard », parée au décollage. Évalué à 3.
cf
http://wiki.mandriva.com/en/2010.1_Development
[^] # Re: La 3D... La couleur... est-ce mieux ??
Posté par wismerhill . En réponse au journal Sintel, libérez vos rétines. Évalué à 1.
Ben si, c'est exactement ça qu'il y a dans les cinémas, des lunettes actives.
Tu ne croyais quand même pas que les gens allaient voir des films et rouge et vert??
À la limite des lunettes polarisantes, mais c'est pas génial pour le confort visuel car le filtrage n'est pas parfait et il faut garder la tête bien droite.
[^] # Re: Comparaison avec Eclipse
Posté par wismerhill . En réponse à la dépêche Sortie de KDevelop 4.0. Évalué à 1.
(la première version de konqueror, qui est un gros conteneur de kpart, est arrivée avec KDE 2.0)
# Lecteur RSS
Posté par wismerhill . En réponse au message developper une petite application kde. Évalué à 2.
[^] # Re: Ma Solution a moi
Posté par wismerhill . En réponse au journal Apache vs Cherokee / PostgreSQL vs MySql. Évalué à 4.
Hum :-)
SQLite est une base de données.
La différence avec les autres plus connu est que c'est une DB embarquée et pas un serveur.
(certains, comme mysql derby ou firebird, peuvent aussi être embarqués)
[^] # Re: .
Posté par wismerhill . En réponse au journal Le point sur Java 7. Évalué à 2.
Tu semble considérer que ne pas trouver ton machin est une erreur.
Moi ça me semble plutôt un comportement tout à fait normal, on cherche un certain machin, si on le trouve on en fera quelque chose sinon on fera autre chose.
C'est au code appellant de savoir si ne pas trouver de machin est une erreur (le machin aurait du être là) où une situation normale.
Seule la méthode getMachinById() doit connaitre la nomenclature d'un Id
Ça c'est un autre problème, si l'ID a une nomenclature particulière et n'accepte pas n'importe quelle valeur il faut que la méthode lance une exception (genre IllegalArgumentException) si la valeur passée est invalide.
Mais si la valeur passée est acceptable, il ne faut pas lancer d'exception simplement parce qu'on ne trouve rien.
Image la classe Map qui lancerait une exception dans son get simplement parce que la clé donnée n'est pas présente dans le Map (d'autant que certaines implémentations acceptent null en valeur, et peuvent donc retourner null même si la clé est présente).
L'argument des performances pour la gestion des exceptions est fallacieux. Les exceptions ça va vite, et bien que ce soit verbeux, c'est lisible.
Lancer une exception nécessite de construire le stacktrace de l'endroit qui a lancé l'exception (souvent quelque dizaines de StackTraceElement), ça me semble quand même significativement plus lourd que de simplement retourner null (quand c'est pertinent par rapprot à la sémentique de la méthode) qui ne va allouer aucune mémoire.
Les exceptions ne sont pas là pour indiquer que le programme va partir en sucette à partir de maintenant. Elles sont là pour rendre plus clair le déroulement d'un programme.
On n'a vraisemblablement pas la même notion de clareté d'un code.
[^] # Re: .
Posté par wismerhill . En réponse au journal Le point sur Java 7. Évalué à 8.
D'autant qu'il est beaucoup plus efficace de retourner un null et le tester au retour plutôt que de lancer des exceptions et de jouer du try{}catch(){}.
Les exceptions ne sont pas faites pour gérer le fonctionnement normal du programme, si une exception est lancée ça indique qu'il y a un problème.
(une petite recherche sur "exception flow control" donne plein de discussions sur le sujet)
[^] # Re: Question
Posté par wismerhill . En réponse au journal [OSM] Mappy veut bien piller mais pas contribuer. Évalué à 2.
D'ailleurs, si tu clique sur la croix en haut à droite tu peux choisir d'autres rendus, et il y a d'autres sites qui proposent des cartes spécialisée, comme par exemple cloudmade ( http://maps.cloudmade.com/ ) qui propose un service de routage (qui reste un peu aléatoire dans les zones incomplètes).
Un autre exemple amusant: un rendu des vitesse maximales http://maxspeed.osm.lab.rfc822.org/
La carte de la page principale est uniquement un aperçu de ce qu'on peut faire avec les données, ça leur coute déjà cher d'avoir des serveurs qui tiennent la charge avec un recalcul en permanence des images (car les données évoluent en continu).
[^] # Re: Mysql racheté
Posté par wismerhill . En réponse au message Versions de MySQL?!?. Évalué à 1.
Il y a aussi firebird
http://www.firebirdsql.org/
qui était à l'origne un fork d'interbase 6 (pendant la période où il a été opensource) et qui est un vrai SGBDR.
Les dernières version rattrapent le retard en terme de fonctionnalité (avant la version 2.0 il y avait vraiment très peu de fonctions de base), le développement est bien actif mais il souffre un peu de sa communauté réduite par rapport aux poids-lourds que sont MySQL et PostgreSQL.
[^] # Re: Métaphore
Posté par wismerhill . En réponse au journal Attention chérie, ça va se heurter.... Évalué à 10.
# Midnight commander
Posté par wismerhill . En réponse au message Utilisation pratique d'openssh. Évalué à 3.
À mon avis c'est un incontournable!
[^] # Re: Questions aux lecteurs
Posté par wismerhill . En réponse à la dépêche Nouvelle version 2.6.33 du noyau Linux. Évalué à 2.
C'est toujours un plaisir de voir arriver une de tes dépêches car les sujets sont bien traités avec plein de liens extérieurs pour approfondir.
[^] # Re: Question idiote
Posté par wismerhill . En réponse au journal [HS] Roland Magdane, un plagiat comme un autre. Évalué à 1.
[^] # Re: Question idiote
Posté par wismerhill . En réponse au journal [HS] Roland Magdane, un plagiat comme un autre. Évalué à 3.
prenons un exemple frappant:
Jirō_Taniguchi
et puis quelques autres que j'apprécie particulièrement
Kei_Toume
Naoki_Urasawa
Tsukasa_Hōjō
et puis du côté des animé
Hayao_Miyazaki et le Studio_Ghibli
[^] # Re: Et ça fait quelle taille dans les pages à charger?
Posté par wismerhill . En réponse au journal Un environnement d'exécution Flash en ... Javascript. Évalué à 0.
Ça a pris (et prend encore) du temps pour atteindre un niveau de fonctionnalités équivalent mais ça permettra d'aller beaucoup plus loin dans l'avenir.
[^] # Re: fsync ?
Posté par wismerhill . En réponse au journal Cache du système de fichier en RAM. Évalué à 1.
Sauf que le format sur le disque du FS n'est pas encore strictement fixé (même s'il faut une très bonne raison pour qu'il change encore).
cf http://btrfs.wiki.kernel.org/index.php/FAQ
Par exemple il a changé dans le 2.6.31, qui sait lire l'ancien format mais réécrit de façon un peu différente, donc une fois utilisé avec un 2.6.>=31 ce n'est plus lisible par un précédent (à moins de le patcher avec la dernière version de btrfs, ce qui semble prévu d'après la FAQ).