Il a une courbe d'apprentissage intéressante, mais c'est la même chose avec les gros IDE. Tu commence à apprendre le fonctionnement du logiciel et quand tu en comprend les principes, tu peut facilement réutiliser ces acquis pour de l'ensemble des fonctions du logiciel.
Je comprends bien, je suis souvent tenté, il ne faut pas croire, je sais bien que dans certaines circonstances ça me serait utile. Mais ce qui m'embêterait le plus c'est d'avoir à passer du temps à chercher quel IDE et ensuite le changer. Rien que sur ce journal on a vu plusieurs noms défiler. Les IDE d'aujourd'hui n'ont vraiment rien à voir avec ceux d'il y a 10 ou 20 ans, peut-être qu'eclipse sera l'exception. Pareil pour n'importe quelle interface graphique, WM etc. d'ailleurs.
Tandis qu'avec vim je ne me pose plus de question (à part pour mouler ici !), c'est un gain de temps appréciable.
Je pense que les IDE java sont venu avec le besoin. Personnellement j'ai senti l'intérêt des IDE avec java et j'ai senti que je n'en avais plus besoin avec python. Et je n'en avais pas besoin en C mais ça fait très longtemps, à l'époque la doc tenait dans un seul bouquin et le code était très concis.
Mais je n'ai toujours fais que des spécifs très concis, et généralement seul, pas d'usines à gaz… Donc je ne témoigne que de mon cas particulier.
Si j'avais du démarrer la prog avec obligation d'utiliser un IDE, je ne pense pas que j'aurai continué !
Tu n'es pas le seul non… Je préfère même des bugs qui lèvent des exceptions, au moins je sais tout de suite ce qui ce passe qu'un bug "utilisateur" où le programme est tout content mais le résultat bancal.
Pas plus tard que le mois dernier, sur ma déclaration contrôlée (par une "association de gestion agréée", pas des amateurs non ?), j'ai réussi sans le faire exprès à modifier ma déclaration de l'année précédente ! Tout ça parce qu'ils n'avaient pas prévu qu'on consulte dans un onglet en même temps qu'on saisisse dans un autre. Un debugger dans ce cas ne servira pas à grand chose…
Je n'utilise pratiquement jamais de debugger, par contre je génère toujours une tonne de logs sur l'utilisation. En python on a de très belles traces ça permet assez rapidement de voir où est le problème dans le code, par contre ce qui est plus dur c'est de savoir par quel cheminement l'utilisateur est arrivé jusque là !
Il a dit que la courbe d'apprentissage des IDE était difficile, celles d'emacs ou de vim sont horribles. Rien est intuitif dans ces éditeurs.
Je pense que tu dis ça parce que tu les utilise comme des IDE, dans ce cas effectivement la courbe d'apprentissage est sans fin. C'est un peu comme si on veut utiliser firefox avec une centaine de plugin tout de suite.
J'ai eu la chance d'apprendre Vi (pas vim) à l'époque où les possibilités étaient très réduites mais néanmoins énormes par rapport aux éditeurs à la ligne. La courbe d'apprentissage était vraiment courte, et les commandes très intuitives. w=word i=insert a=append… J'avais un seul livre "la prog sous linux" de rifflet, la doc pour utiliser vi tien sur 6 pages.
Maintenant c'est vrai que c'est parfois tentant de reproduire un ide avec, mais on s'écarte de la philosophie d'unix tu as raison et on retombe exactement dans les mêmes travers qu'avec les ide. (tu remarqueras que je ne parle que de vi, pas d'emacs !)
Je suis également d'accord avec toi comme j'ai dis dans un autre commentaire, ça dépend de l'utilisateur, parfois du langage…
Je voulais juste témoigner sur le fait qu'il est possible d'utiliser un simple éditeur de texte ultra efficace pendant des décennies sans se prendre la tête avec des ide.
Après, je pense que si tu n'es pas un gros codeur Java, tu ne peux pas avoir le même ressenti que "nous". Java Enterprise Edition est une telle soupe, avec son milliard d'API, d'outils connexes, de code lourdingue à taper/gérer, que sans un IDE tu y passes tes nuits.
C'est clair qu'il y a des langages qui demandent un ide beaucoup plus que d'autres. La seule fois où j'en ai eu besoin c'était pour du java justement.
De la même manière, ça dépend aussi de ce qu'on code. Si on arrive à rester dans la philosophie unix à découper le problème en plusieurs petites taches on a beaucoup moins besoin d'un ide que si on code une usine à gaz.
La courbe d'apprentissage il faut la comparer à la durée et à la plage d'utilisation. Vi c'est un investissement sur le long terme, des dizaines d'années, et utilisable absolument de partout (pour taper ce texte par exemple). Tandis que les IDE les plus sophistiqués ont une durée de vie très courte et une plage d'utilisation extrêmement réduite donc la courbe d'apprentissage sera à répéter sans cesse.
Le principe d'unix de ne faire qu'une chose mais bien a fait ces preuves.
A propos d'architecture est-ce possible à partir de maintenant d'upgrader d'une archi à l'autre sans refaire une installation ou c'est encore pour plus tard ? Sur une page du wiki ça n'est pas très clair…
A propos de postgresql et du multi-architecture, est-ce qu'il est du coup possible d'installer deux versions d'architectures différentes ? Ce serait vraiment pratique pour pouvoir répliquer des bdd venant de machines de différentes archis !
Et est-ce qu'en utilisant apt.postgresql.org on bénéficie également de cette multi-architecture ?
qui est quoi en cours d'utilisation
…
Je me contrefiche des performances. Par contre, le but du jeu est d'être le plus pédagogique possible
Dans ce cas, qu'est-ce que ça changerait que le type soit vérifié à la compilation ou à l'exécution ?
C'est un peu comme si tu voulais enseigner l'orthographe avec un correcteur orthographique !
Même si tu spécifie les types ça n'enlèvera rien au problème pédagogique de ne pas vérifier ce qui rentre et sort. Le type statique c'est surtout pour la pédagogie du compilateur. Pour le programmeur ça n'est qu'une erreur pas plus courante qu'une autre.
Quel est la différence entre 5 + "a" et datetime(123,32,201) ?
La première pourrait éventuellement être détecté à la compilation, mais la deuxième non. Alors pourquoi ajouter une technique qui vérifiera la première mais pas la deuxième ?
En revanche avec des tests unitaires on vérifiera aussi bien la deuxième (la plus courante !) que la première. Pédagogiquement c'est d'une pierre deux coups et ça marche avec n'importe quel langage.
Posté par wilk .
En réponse au journal Paperless....
Évalué à 9.
J'ai modifié mon bug tracker perso pour gérer ça. J'ai des projets impots/urssaf/logement/… dans chaque projets des tags tva/2035/… Par exemple je crée une requête "impots 2012", j'y ajoute les divers documents en fichiers joints. Ce qu'il y a de pratique avec le système de bug tracker c'est que je peux indiquer si c'est terminé, en cours etc… et également y ajouter des commentaires si par exemple j'ai des échanges avec les impots "envoi demande de document xyz", "reçu document", "appel pour info" etc…
Je me suis même payé le luxe d'extraire le texte d'un fichier joint en pdf et de l'indexer en full text avec postgresql.
Ca ne serait pas très pratique pour gérer des milliers de docs partagés par des dizaines de collaborateurs, mais pour ma tpe, famille et petites assos ça va très bien et ça ne me fait pas utiliser un nouvel outil que celui avec lequel je dev.
Pas trouvé de doc non plus, dans le lien que tu indiques il y a quelque chose qui ne me parait pas des plus simple :
As I understood it, the only way to deal with users is to create system users ; in /etc/passwd. They don’t have to be able to log in ; they just need a home, to store email, and a password, for authenticated smtp.
Il faudrait que chaque compte mail soit un compte unix… Sans doute qu'il n'a pas trouvé la doc non plus ?
Pourquoi vouloir réaliser très vite des formulaires ? Faciliter les choses simples ça n'est pas la peine elles sont déjà simples. Il vaut mieux se faciliter les choses compliquées, et donc éviter tout ce qui est trop générique.
Ne détourne pas le sujet, ce qui est intéressant c'est l'analogie avec les logiciels libres, avec wikipedia, avec internet… Tout ceux qui disaient que seule une solution centralisée pourra marcher se sont vautrés (ce que dit Fleur, on cause de ça).
Souviens toi de la phrase du président d'ibm en 1943 «Je pense qu'il y a un marché mondial pour environ 5 ordinateurs.»
C'est une analogie, ça n'est pas une solution pratique de faire transiter l'électricité par internet !
Il préconise juste d'écouter ceux qui innovent, pas les dinosaures.
Si j'ai une alerte le jour où il y a une grève c'est pas grave, ça me permettra de vérifier que le système fonctionne… Le tout c'est de ne pas avoir une alerte tous les dimanches par ex.
anti-nucléaires "classiques" dogmatiques et menteurs
Faut arrêter d'être jaloux de ceux qui ont eu raison trop tôt…
Rappelles-toi comment on était traité il n'y a pas si longtemps à propos des logiciels libres !
C'est ce que je voudrais faire, mais il me reste un problème avec les tables qui n'évoluent pas de la même manière suivant le jour de la semaine, voir du mois.
Il n'y a pas que les socialistes, on ne voit plus trop la différence à ce niveau là…
Par contre j'ai été surpris d'écouter cet économiste jeremy rifkin, qui bien que pas très barbu ni petit à l'air d'avoir compris le système que les "petits" vont mettre en place ! http://www.dailymotion.com/video/xjwyx0_jeremy-rifkin-le-nucleaire-est-mort_webcam
Non, ce que je veux maintenant c'est m'assurer de la cohérence des données en elles-mêmes. C'est plus en cas de problème de l'application que du moteur de base de données.
Ce qui m'est arrivé par exemple c'est de déplacer une base sur un autre cluster et de continuer à sauvegarder l'ancien cluster. Ainsi je n'avais aucun problème de sauvegarde mais la base en question n'évoluait plus bien sûr. Je cherche donc un moyen de vérifier automatiquement que telle table de telle base continue à progresser comme d'habitude, que j'ai bien une moyenne de 10 commandes par jour sauf le we et que j'ai bien x bulletins de paye tous les mois etc… Ainsi je suis sûr que 1. je sauvegarde bien la bonne base et que 2. l'application fonctionne comme d'hab.
Effectivement j'ai mélangé les deux sujets. Ce que je voulais surtout dire c'est qu'il ne suffit pas de répliquer ou sauvegarder, il faut également vérifier la cohérence des données. Je pourrais aussi m'occuper de la cohérence des données sans réplication ni backup mais généralement ça va ensemble c'est tout.
[^] # Re: Non, mais ...
Posté par wilk . En réponse au journal Point de vue : un IDE est il un outil de programmation indispensable ?. Évalué à 1.
Je comprends bien, je suis souvent tenté, il ne faut pas croire, je sais bien que dans certaines circonstances ça me serait utile. Mais ce qui m'embêterait le plus c'est d'avoir à passer du temps à chercher quel IDE et ensuite le changer. Rien que sur ce journal on a vu plusieurs noms défiler. Les IDE d'aujourd'hui n'ont vraiment rien à voir avec ceux d'il y a 10 ou 20 ans, peut-être qu'eclipse sera l'exception. Pareil pour n'importe quelle interface graphique, WM etc. d'ailleurs.
Tandis qu'avec vim je ne me pose plus de question (à part pour mouler ici !), c'est un gain de temps appréciable.
[^] # Re: Non, mais ...
Posté par wilk . En réponse au journal Point de vue : un IDE est il un outil de programmation indispensable ?. Évalué à 2.
Je pense que les IDE java sont venu avec le besoin. Personnellement j'ai senti l'intérêt des IDE avec java et j'ai senti que je n'en avais plus besoin avec python. Et je n'en avais pas besoin en C mais ça fait très longtemps, à l'époque la doc tenait dans un seul bouquin et le code était très concis.
Mais je n'ai toujours fais que des spécifs très concis, et généralement seul, pas d'usines à gaz… Donc je ne témoigne que de mon cas particulier.
Si j'avais du démarrer la prog avec obligation d'utiliser un IDE, je ne pense pas que j'aurai continué !
[^] # Re: Pas si on est un grand ponte apparemment.
Posté par wilk . En réponse au journal Un debugger est-il indispensable ?. Évalué à 2.
Tu n'es pas le seul non… Je préfère même des bugs qui lèvent des exceptions, au moins je sais tout de suite ce qui ce passe qu'un bug "utilisateur" où le programme est tout content mais le résultat bancal.
Pas plus tard que le mois dernier, sur ma déclaration contrôlée (par une "association de gestion agréée", pas des amateurs non ?), j'ai réussi sans le faire exprès à modifier ma déclaration de l'année précédente ! Tout ça parce qu'ils n'avaient pas prévu qu'on consulte dans un onglet en même temps qu'on saisisse dans un autre. Un debugger dans ce cas ne servira pas à grand chose…
# logs d'utilisation
Posté par wilk . En réponse au journal Un debugger est-il indispensable ?. Évalué à 1.
Je n'utilise pratiquement jamais de debugger, par contre je génère toujours une tonne de logs sur l'utilisation. En python on a de très belles traces ça permet assez rapidement de voir où est le problème dans le code, par contre ce qui est plus dur c'est de savoir par quel cheminement l'utilisateur est arrivé jusque là !
[^] # Re: Non, mais ...
Posté par wilk . En réponse au journal Point de vue : un IDE est il un outil de programmation indispensable ?. Évalué à 3.
Je pense que tu dis ça parce que tu les utilise comme des IDE, dans ce cas effectivement la courbe d'apprentissage est sans fin. C'est un peu comme si on veut utiliser firefox avec une centaine de plugin tout de suite.
J'ai eu la chance d'apprendre Vi (pas vim) à l'époque où les possibilités étaient très réduites mais néanmoins énormes par rapport aux éditeurs à la ligne. La courbe d'apprentissage était vraiment courte, et les commandes très intuitives. w=word i=insert a=append… J'avais un seul livre "la prog sous linux" de rifflet, la doc pour utiliser vi tien sur 6 pages.
Maintenant c'est vrai que c'est parfois tentant de reproduire un ide avec, mais on s'écarte de la philosophie d'unix tu as raison et on retombe exactement dans les mêmes travers qu'avec les ide. (tu remarqueras que je ne parle que de vi, pas d'emacs !)
Je suis également d'accord avec toi comme j'ai dis dans un autre commentaire, ça dépend de l'utilisateur, parfois du langage…
Je voulais juste témoigner sur le fait qu'il est possible d'utiliser un simple éditeur de texte ultra efficace pendant des décennies sans se prendre la tête avec des ide.
[^] # Re: Non, mais ...
Posté par wilk . En réponse au journal Point de vue : un IDE est il un outil de programmation indispensable ?. Évalué à -2.
Je ne connais pas eclipse, mais généralement les ide même sans en changer il faut continuellement rester au jus, je me trompe ?
[^] # Re: Non, mais ...
Posté par wilk . En réponse au journal Point de vue : un IDE est il un outil de programmation indispensable ?. Évalué à 3.
C'est clair qu'il y a des langages qui demandent un ide beaucoup plus que d'autres. La seule fois où j'en ai eu besoin c'était pour du java justement.
De la même manière, ça dépend aussi de ce qu'on code. Si on arrive à rester dans la philosophie unix à découper le problème en plusieurs petites taches on a beaucoup moins besoin d'un ide que si on code une usine à gaz.
[^] # Re: Non, mais ...
Posté par wilk . En réponse au journal Point de vue : un IDE est il un outil de programmation indispensable ?. Évalué à 2.
La courbe d'apprentissage il faut la comparer à la durée et à la plage d'utilisation. Vi c'est un investissement sur le long terme, des dizaines d'années, et utilisable absolument de partout (pour taper ce texte par exemple). Tandis que les IDE les plus sophistiqués ont une durée de vie très courte et une plage d'utilisation extrêmement réduite donc la courbe d'apprentissage sera à répéter sans cesse.
Le principe d'unix de ne faire qu'une chose mais bien a fait ces preuves.
[^] # Re: Architecture
Posté par wilk . En réponse à la dépêche Debian : Épisode VII. Évalué à 3.
A propos d'architecture est-ce possible à partir de maintenant d'upgrader d'une archi à l'autre sans refaire une installation ou c'est encore pour plus tard ? Sur une page du wiki ça n'est pas très clair…
[^] # Re: Attention: postgresql
Posté par wilk . En réponse à la dépêche Debian : Épisode VII. Évalué à 2.
A propos de postgresql et du multi-architecture, est-ce qu'il est du coup possible d'installer deux versions d'architectures différentes ? Ce serait vraiment pratique pour pouvoir répliquer des bdd venant de machines de différentes archis !
Et est-ce qu'en utilisant apt.postgresql.org on bénéficie également de cette multi-architecture ?
# bug tracker
Posté par wilk . En réponse au journal Où se trouvent les services GTD libres !?. Évalué à 1.
Même réponse que pour le journal paperless, je détourne mon bug tracker…
Mais j'avoue que je ne me suis jamais préoccupé de la potabilité avec android vu que c'est une appli web, j'y accède avec un navigateur et basta.
[^] # Re: le python a un typage dynamique
Posté par wilk . En réponse au journal [MyFirstPython, nouveau projet ?]Le python c'est bien mangez-en !!. Évalué à 1.
Dans ce cas, qu'est-ce que ça changerait que le type soit vérifié à la compilation ou à l'exécution ?
C'est un peu comme si tu voulais enseigner l'orthographe avec un correcteur orthographique !
[^] # Re: Validité ?
Posté par wilk . En réponse au journal Paperless.... Évalué à 3.
Il faut les garder quand même, mais simplement classés par date et bêtement empilés puisqu'on pourra les retrouver facilement avec l'index numérique.
# tests unitaires
Posté par wilk . En réponse au journal [MyFirstPython, nouveau projet ?]Le python c'est bien mangez-en !!. Évalué à 1.
Même si tu spécifie les types ça n'enlèvera rien au problème pédagogique de ne pas vérifier ce qui rentre et sort. Le type statique c'est surtout pour la pédagogie du compilateur. Pour le programmeur ça n'est qu'une erreur pas plus courante qu'une autre.
Quel est la différence entre 5 + "a" et datetime(123,32,201) ?
La première pourrait éventuellement être détecté à la compilation, mais la deuxième non. Alors pourquoi ajouter une technique qui vérifiera la première mais pas la deuxième ?
En revanche avec des tests unitaires on vérifiera aussi bien la deuxième (la plus courante !) que la première. Pédagogiquement c'est d'une pierre deux coups et ça marche avec n'importe quel langage.
# bug tracker
Posté par wilk . En réponse au journal Paperless.... Évalué à 9.
J'ai modifié mon bug tracker perso pour gérer ça. J'ai des projets impots/urssaf/logement/… dans chaque projets des tags tva/2035/… Par exemple je crée une requête "impots 2012", j'y ajoute les divers documents en fichiers joints. Ce qu'il y a de pratique avec le système de bug tracker c'est que je peux indiquer si c'est terminé, en cours etc… et également y ajouter des commentaires si par exemple j'ai des échanges avec les impots "envoi demande de document xyz", "reçu document", "appel pour info" etc…
Je me suis même payé le luxe d'extraire le texte d'un fichier joint en pdf et de l'indexer en full text avec postgresql.
Ca ne serait pas très pratique pour gérer des milliers de docs partagés par des dizaines de collaborateurs, mais pour ma tpe, famille et petites assos ça va très bien et ça ne me fait pas utiliser un nouvel outil que celui avec lequel je dev.
[^] # Re: Plus simple que Postfix ?
Posté par wilk . En réponse à la dépêche OpenSMTPD 5.3 est de sortie !. Évalué à 2.
Pas trouvé de doc non plus, dans le lien que tu indiques il y a quelque chose qui ne me parait pas des plus simple :
Il faudrait que chaque compte mail soit un compte unix… Sans doute qu'il n'a pas trouvé la doc non plus ?
[^] # Re: demande proche ?
Posté par wilk . En réponse au message Framework php pour formulaire bd ?. Évalué à 0.
Pourquoi vouloir réaliser très vite des formulaires ? Faciliter les choses simples ça n'est pas la peine elles sont déjà simples. Il vaut mieux se faciliter les choses compliquées, et donc éviter tout ce qui est trop générique.
[^] # Re: Les petits fragilisent les gros !
Posté par wilk . En réponse à la dépêche États généraux de l'Open Source en France. Évalué à 2.
Ca tombe bien, la gestion du pic est justement l'une des choses où on va avoir besoin d'internet et d'ingéniosité. http://fr.wikipedia.org/wiki/Smart_grid
[^] # Re: Les petits fragilisent les gros !
Posté par wilk . En réponse à la dépêche États généraux de l'Open Source en France. Évalué à 4.
Ne détourne pas le sujet, ce qui est intéressant c'est l'analogie avec les logiciels libres, avec wikipedia, avec internet… Tout ceux qui disaient que seule une solution centralisée pourra marcher se sont vautrés (ce que dit Fleur, on cause de ça).
Souviens toi de la phrase du président d'ibm en 1943 «Je pense qu'il y a un marché mondial pour environ 5 ordinateurs.»
C'est une analogie, ça n'est pas une solution pratique de faire transiter l'électricité par internet !
Il préconise juste d'écouter ceux qui innovent, pas les dinosaures.
[^] # Re: Pour le monitoring fonctionnel
Posté par wilk . En réponse au message Cohérence de l'évolution des données. Évalué à 1.
Si j'ai une alerte le jour où il y a une grève c'est pas grave, ça me permettra de vérifier que le système fonctionne… Le tout c'est de ne pas avoir une alerte tous les dimanches par ex.
[^] # Re: Les petits fragilisent les gros !
Posté par wilk . En réponse à la dépêche États généraux de l'Open Source en France. Évalué à 2.
Faut arrêter d'être jaloux de ceux qui ont eu raison trop tôt…
Rappelles-toi comment on était traité il n'y a pas si longtemps à propos des logiciels libres !
[^] # Re: Pour le monitoring fonctionnel
Posté par wilk . En réponse au message Cohérence de l'évolution des données. Évalué à 1.
C'est ce que je voudrais faire, mais il me reste un problème avec les tables qui n'évoluent pas de la même manière suivant le jour de la semaine, voir du mois.
[^] # Re: Les petits fragilisent les gros !
Posté par wilk . En réponse à la dépêche États généraux de l'Open Source en France. Évalué à 3.
Il n'y a pas que les socialistes, on ne voit plus trop la différence à ce niveau là…
Par contre j'ai été surpris d'écouter cet économiste jeremy rifkin, qui bien que pas très barbu ni petit à l'air d'avoir compris le système que les "petits" vont mettre en place !
http://www.dailymotion.com/video/xjwyx0_jeremy-rifkin-le-nucleaire-est-mort_webcam
[^] # Re: Monitoring?
Posté par wilk . En réponse au message Cohérence de l'évolution des données. Évalué à -1.
Monitoring, j'ai déjà…
Non, ce que je veux maintenant c'est m'assurer de la cohérence des données en elles-mêmes. C'est plus en cas de problème de l'application que du moteur de base de données.
Ce qui m'est arrivé par exemple c'est de déplacer une base sur un autre cluster et de continuer à sauvegarder l'ancien cluster. Ainsi je n'avais aucun problème de sauvegarde mais la base en question n'évoluait plus bien sûr. Je cherche donc un moyen de vérifier automatiquement que telle table de telle base continue à progresser comme d'habitude, que j'ai bien une moyenne de 10 commandes par jour sauf le we et que j'ai bien x bulletins de paye tous les mois etc… Ainsi je suis sûr que 1. je sauvegarde bien la bonne base et que 2. l'application fonctionne comme d'hab.
[^] # Re: Réplication != sauvegarde
Posté par wilk . En réponse au message Cohérence de l'évolution des données. Évalué à 2.
Effectivement j'ai mélangé les deux sujets. Ce que je voulais surtout dire c'est qu'il ne suffit pas de répliquer ou sauvegarder, il faut également vérifier la cohérence des données. Je pourrais aussi m'occuper de la cohérence des données sans réplication ni backup mais généralement ça va ensemble c'est tout.