Quel problème pour la TVA puisque tu ne la facture pas ? Par contre il faut bien que tes clients comprennent que le jour où tu changera de statut il faudra que tu la leur facture en plus ! Si c'est des entreprises ça ne posera aucun problème par contre pour les particulier oui...
Comment tu fait pour les serveurs que tu loue ? vu que tu ne peux pas les passer en charge, est-ce que tu fait payer tes clients directement à ton fournisseur ?
C'est l'intégration de code (dans du xml) tout court qui n'est pas aisée ! De fait, dès que le code dépasse 2 lignes généralement il est dans un fichier à part. Au pire il est dans les balises script et il a plutôt intérêt à être correctement indenté, que ce soit indispensable ou non.
Si plusieurs personnes mettent leur branche en ligne il y aura plusieurs wiki simultanés à synchroniser par la suite ? En tout cas l'idée est intéressante car on fait souvent des aller-retour entre un wiki en ligne et la doc, ça mériterait d'être expérimenté sur d'autres dvcs.
Comment on modifie le wiki et le bug tracker ? Sur leur site je ne vois pas la possibilité en ligne, est-ce qu'il faut passer par une branche et éditer sur cette branche hors ligne comme on le fait en éditant le fichier todo ou une page de doc sur un projet classique ?
A priori je ne cherche pas à réécrire l'historique... J'utilise rebase, pour rester synchro avec la branche principale sans avoir à faire des merges à tout bout de champ (hg pull --rebase va récupérer ce qui me manque de la branche principale et remettre mes patchs à la fin). Eventuellement j'utilise rebase --collapse pour regrouper mes patchs en un seul avant de tout renvoyer sur la principale.
Avant de pousser sur le dépot public, je fait donc pas mal de nettoyage sur tous les commit fait un peu partout. Je réécrit donc un historique de commits propres
Tu fais comment exactement cette réécriture de l'historique ? J'aimerai comparer ça avec Mercurial.
Et si tu te posais la question dans l'autre sens ? Que dirais-tu a quelqu'un qui se demande s'il doit passer de Mercurial à Subversion ? Surtout pour du dev seul ou il n'y a pas besoin de verrouiller un fichier. C'est de plus en plus difficile à comparer avec Subversion tant on commence à l'oublier... Pour ma part je suis passé directement de CVS à un DVCS (Mercurial maintenant). Pour résumer je dirai que c'est tellement plus simple (de l'installation à l'utilisation).
Les commits locaux deviendrons vite indispensables. Commit locaux ça peut vouloir dire sur la même machine dans un répertoire différent, pour tester une nouvelle fonctionnalité qui sera soit complètement abandonnée (rm du répertoire tout simplement), soit fusionnée sans soucis dès qu'elle est prête. Si le développement de cette fonctionnalité s'éternise elle restera facilement en phase avec la branche principale.
Il y a plein d'endroit où on peut trouver des arguments pour comparer le centralisé et le décentralisé, toutes les mailing-listes (et wiki) des projets libres qui ont fait le pas par ex. Mais c'est vrai qu'on met toujours en avant le travail en groupe. Personnellement, je travaille beaucoup seul et j'y trouve un intérêt aussi. Dès qu'on crée une branche c'est comme si on était 2 et ainsi de suite... J'suis une bande de développeur à moi tout seul je m'fend la gueule ;-) Et le jour ou un autre dev veut participer, tout est prêt, aucune configuration à faire, aucun risque... Pour improviser un petit sprint par ex, c'est un jeu d'enfant.
Autocompletion pour les langages trop verbeux [...]
Ca n'est absolument pas une faiblesse du langage, au contraire, c'est la nature du langage qui permet d'obtenir une autocomplétion intuitive
Simplement, plus il y a du texte à taper plus ça devient indispensable. En python je n'utilise jamais d'autocompletion (je pourrai), en java tout le temps... C'est juste une constatation, quand je programmais en Java j'avais besoin d'un ide le plus sophistiqué possible, en python j'utilise vim avec très peu de plugins et pourtant c'est pour exactement les mêmes programmes (réécris). Par contre je ne pourrai pas utiliser Python sans un ide avec l'auto-indentation.
quand on choisit une plateforme de développement, on prends en compte le langage et les outils.
L'ide est souvent là pour compenser les faiblesses du langage. Autocompletion pour les langages trop verbeux, auto indentation pour python, correction de syntaxe à la volée pour syntaxe trop $;]}, accès rapide à la doc quand c'est pas intuitif...
Je me pose également une question existentielle. Pourquoi les développeurs donnent tant d'importance aux erreurs de typage lorsqu'ils en sont protégés et non ceux qui devraient en être les victimes ? Pour ma part, non plus, la seule fois que je me souvienne d'avoir été embêté avec des erreurs de typage c'est quand je suis passé en unicode. Mis à part ça je ne me souviens pas que ça m'ait posé de problème, quelqu'en soit le langage.
Il faut maintenant regarder du côté de PyPy si on a besoin de performance pure du langage (ce qui est rarement le cas). Les résultats sont considérables dans certains domaines et ça continue à progresser sans arrêt.
Sur un programme de calcul d'itinéraire on a eu un facteur supérieur à 10 sans changer une ligne de code !
Ce qui est marrant dans ce projet c'est qu'au départ le programme était écrit en C, il était trop lent et trop complexe, il a été réécrit en Python pour servir de prototype avec d'autres algorithmes. Résultat le prototype est allé 10x plus vite qu'en C car la facilité de programmation à permis de se concentrer sur l'algo, on l'a gardé comme ça en prod pour faciliter la maintenance (qui est finalement nulle). On a été tenté de le transcrire en Java mais des tests sur le même genre d'algo n'ont montré qu'un gain très faible pour une complexité bien supérieure.
Une durée longue de release est à double tranchant. D'un côté ça limite le nombre d'upgrade mais d'un autre côté ça les rends plus difficiles, avec d'avantages de changements d'un seul coup. Inversement des releases fréquentes limitent le nombre de changements pour chacune et les rends plus simples, parfois insignifiantes. Je me souviens encore de la migration où on est passé d'exim3 à 4 apache 1 à 2 et iso8859 à utf8 ! une horreur ! En revanche de la lenny à la squeeze pour moi ça a été insignifiant.
NGINX n'est pas fait que pour les sites avec fort traffic, il est également particulièrement adapté aux petites configs genre serveurs virtuels. C'est peut-être de cette "mode" qu'il s'agit. C'est à dire de passer d'hébergements mutualisés avec php à des hébergement sur serveurs virtuels et des applis web en mode proxy pour utiliser autre chose que du php.
Les points que tu mentionnent sont spécifique à Java peut-être ? Car en python par exemple on peut très bien déployer une application web sans avoir à installer de serveur http ni apprendre plusieurs langages. OpenERP en est un exemple il me semble. Personnellement il m'arrive de déployer des applications web sous windows à l'aide d'un simple exe.
Ceci dit ça n'a pas grande importance, bravo pour le travail et sa diffusion.
Bruno, tu as démontré que tu pouvais faire faire beaucoup mieux que la plupart des boites spécialisées. En tant que vieux briscard de la prog, je suis impressionné et je te tire mon chapeau pour cette mise en production.
Je préfère pouvoir importer à l'aide d'une API d'une part pour pouvoir comprendre l'outil et aussi parce que j'ai fait beaucoup de spécifs qui en ont besoin (par exemple de la réplication agence/siege, prise de commande à distance etc.) et j'aimerai bien voir ce que ça donnerait avec openerp.
J'ai également un peu de mal avec la doc développeur (que je n'ai fait que survoler je l'avoue). Par exemple pour commencer j'aimerai importer des données clients, produits, devis, factures etc... Je pensais utiliser xml-rpc, mais où se trouve la liste des fonctions accessibles ? Sinon je pensais taper dans la base postgresql, mais je ne trouve pas non plus de description des tables...
[^] # Re: Petites questions
Posté par wilk . En réponse à la dépêche Création d'entreprise : entretien avec personneAnonymisee, admin système en auto-entreprise. Évalué à 3.
Quel problème pour la TVA puisque tu ne la facture pas ? Par contre il faut bien que tes clients comprennent que le jour où tu changera de statut il faudra que tu la leur facture en plus ! Si c'est des entreprises ça ne posera aucun problème par contre pour les particulier oui...
Comment tu fait pour les serveurs que tu loue ? vu que tu ne peux pas les passer en charge, est-ce que tu fait payer tes clients directement à ton fournisseur ?
[^] # Re: Python
Posté par wilk . En réponse à la dépêche Dart va‐t‐il remplacer JavaScript comme langage dans les navigateurs ?. Évalué à 2.
C'est l'intégration de code (dans du xml) tout court qui n'est pas aisée ! De fait, dès que le code dépasse 2 lignes généralement il est dans un fichier à part. Au pire il est dans les balises script et il a plutôt intérêt à être correctement indenté, que ce soit indispensable ou non.
[^] # Re: fossil?
Posté par wilk . En réponse au message SubVersion vs Mercurial vs Git .... Évalué à 1.
Pour le bug tracker c'est pareil ?
Si plusieurs personnes mettent leur branche en ligne il y aura plusieurs wiki simultanés à synchroniser par la suite ? En tout cas l'idée est intéressante car on fait souvent des aller-retour entre un wiki en ligne et la doc, ça mériterait d'être expérimenté sur d'autres dvcs.
[^] # Re: fossil?
Posté par wilk . En réponse au message SubVersion vs Mercurial vs Git .... Évalué à 2.
Comment on modifie le wiki et le bug tracker ? Sur leur site je ne vois pas la possibilité en ligne, est-ce qu'il faut passer par une branche et éditer sur cette branche hors ligne comme on le fait en éditant le fichier todo ou une page de doc sur un projet classique ?
[^] # Re: Mon utilisation de git ...
Posté par wilk . En réponse au message SubVersion vs Mercurial vs Git .... Évalué à 1.
C'est dans le log final que ça change, au lieu d'avoir p1 p2 merge p3 p4 merge p5 p6 merge j'aurai p1 p2 p3 p4 p5 p6 merge
[^] # Re: Mon utilisation de git ...
Posté par wilk . En réponse au message SubVersion vs Mercurial vs Git .... Évalué à 1.
A priori je ne cherche pas à réécrire l'historique... J'utilise rebase, pour rester synchro avec la branche principale sans avoir à faire des merges à tout bout de champ (hg pull --rebase va récupérer ce qui me manque de la branche principale et remettre mes patchs à la fin). Eventuellement j'utilise rebase --collapse pour regrouper mes patchs en un seul avant de tout renvoyer sur la principale.
Je vois qu'il y a une extension histedit http://mercurial.selenic.com/wiki/HisteditExtension qui a l'air de se rapprocher du rebase git mais je ne l'ai jamais utilisée.
[^] # Re: Mon utilisation de git ...
Posté par wilk . En réponse au message SubVersion vs Mercurial vs Git .... Évalué à 2.
Tu fais comment exactement cette réécriture de l'historique ? J'aimerai comparer ça avec Mercurial.
# L'inverse
Posté par wilk . En réponse au message SubVersion vs Mercurial vs Git .... Évalué à 5.
Et si tu te posais la question dans l'autre sens ? Que dirais-tu a quelqu'un qui se demande s'il doit passer de Mercurial à Subversion ? Surtout pour du dev seul ou il n'y a pas besoin de verrouiller un fichier. C'est de plus en plus difficile à comparer avec Subversion tant on commence à l'oublier... Pour ma part je suis passé directement de CVS à un DVCS (Mercurial maintenant). Pour résumer je dirai que c'est tellement plus simple (de l'installation à l'utilisation).
Les commits locaux deviendrons vite indispensables. Commit locaux ça peut vouloir dire sur la même machine dans un répertoire différent, pour tester une nouvelle fonctionnalité qui sera soit complètement abandonnée (rm du répertoire tout simplement), soit fusionnée sans soucis dès qu'elle est prête. Si le développement de cette fonctionnalité s'éternise elle restera facilement en phase avec la branche principale.
Il y a plein d'endroit où on peut trouver des arguments pour comparer le centralisé et le décentralisé, toutes les mailing-listes (et wiki) des projets libres qui ont fait le pas par ex. Mais c'est vrai qu'on met toujours en avant le travail en groupe. Personnellement, je travaille beaucoup seul et j'y trouve un intérêt aussi. Dès qu'on crée une branche c'est comme si on était 2 et ainsi de suite... J'suis une bande de développeur à moi tout seul je m'fend la gueule ;-) Et le jour ou un autre dev veut participer, tout est prêt, aucune configuration à faire, aucun risque... Pour improviser un petit sprint par ex, c'est un jeu d'enfant.
[^] # Re: Chacun son style
Posté par wilk . En réponse à la dépêche Naissance d'un géant : Java. Évalué à 1.
Simplement, plus il y a du texte à taper plus ça devient indispensable. En python je n'utilise jamais d'autocompletion (je pourrai), en java tout le temps... C'est juste une constatation, quand je programmais en Java j'avais besoin d'un ide le plus sophistiqué possible, en python j'utilise vim avec très peu de plugins et pourtant c'est pour exactement les mêmes programmes (réécris). Par contre je ne pourrai pas utiliser Python sans un ide avec l'auto-indentation.
[^] # Re: Chacun son style
Posté par wilk . En réponse à la dépêche Naissance d'un géant : Java. Évalué à -1.
L'ide est souvent là pour compenser les faiblesses du langage. Autocompletion pour les langages trop verbeux, auto indentation pour python, correction de syntaxe à la volée pour syntaxe trop $;]}, accès rapide à la doc quand c'est pas intuitif...
# Webmail seul
Posté par wilk . En réponse à la dépêche Sortie de Modoboa 0.8.5. Évalué à 1.
Est-ce qu'il est prévu de pouvoir utiliser le webmail seul ?
[^] # Re: et python ? :)
Posté par wilk . En réponse à la dépêche Naissance d'un géant : Java. Évalué à 4.
ton programme prend 10 minutes à se lancer
Déjà là ça commence mal...
Je me pose également une question existentielle. Pourquoi les développeurs donnent tant d'importance aux erreurs de typage lorsqu'ils en sont protégés et non ceux qui devraient en être les victimes ? Pour ma part, non plus, la seule fois que je me souvienne d'avoir été embêté avec des erreurs de typage c'est quand je suis passé en unicode. Mis à part ça je ne me souviens pas que ça m'ait posé de problème, quelqu'en soit le langage.
[^] # Re: et python ? :)
Posté par wilk . En réponse à la dépêche Naissance d'un géant : Java. Évalué à 3.
Il faut maintenant regarder du côté de PyPy si on a besoin de performance pure du langage (ce qui est rarement le cas). Les résultats sont considérables dans certains domaines et ça continue à progresser sans arrêt.
Sur un programme de calcul d'itinéraire on a eu un facteur supérieur à 10 sans changer une ligne de code !
Ce qui est marrant dans ce projet c'est qu'au départ le programme était écrit en C, il était trop lent et trop complexe, il a été réécrit en Python pour servir de prototype avec d'autres algorithmes. Résultat le prototype est allé 10x plus vite qu'en C car la facilité de programmation à permis de se concentrer sur l'algo, on l'a gardé comme ça en prod pour faciliter la maintenance (qui est finalement nulle). On a été tenté de le transcrire en Java mais des tests sur le même genre d'algo n'ont montré qu'un gain très faible pour une complexité bien supérieure.
http://speed.pypy.org/
[^] # Re: Merci le LTS
Posté par wilk . En réponse à la dépêche FreeBSD 8.2 et 7.4 : deux sorties pour le prix d'une. Évalué à 4.
Une durée longue de release est à double tranchant. D'un côté ça limite le nombre d'upgrade mais d'un autre côté ça les rends plus difficiles, avec d'avantages de changements d'un seul coup. Inversement des releases fréquentes limitent le nombre de changements pour chacune et les rends plus simples, parfois insignifiantes. Je me souviens encore de la migration où on est passé d'exim3 à 4 apache 1 à 2 et iso8859 à utf8 ! une horreur ! En revanche de la lenny à la squeeze pour moi ça a été insignifiant.
[^] # Re: Bof ?
Posté par wilk . En réponse au sondage Je trouve la nouvelle version de LinuxFr ..... Évalué à 1.
Bof c'est plutôt un compliment dans le cas d'une migration, ça signifie qu'elle est réussie !
[^] # Re: La ruse de cache sur erreur 404 de Templeet est-elle toujours active ?
Posté par wilk . En réponse à la dépêche Architecture logicielle de la nouvelle version de LinuxFr.org. Évalué à 3.
De quelles possibilités tu parles ? Comment est géré la purge du cache par ex ?
L'authentification de l'utilisateur était gérée en javascript + cookies non ?
[^] # Re: mode avocat du diable
Posté par wilk . En réponse à la dépêche Python 3.2. Évalué à 1.
Dans ce cas ça n'est pas des flottants qu'il faudrait utiliser mais des décimaux.
Ma calculatrice ne m'indique pas
[^] # Re: Je suis français donc je râle
Posté par wilk . En réponse à la dépêche Architecture logicielle de la nouvelle version de LinuxFr.org. Évalué à 1.
Et textile ? Peut-être pas pour les commentaires, mais pour les dépêches ça pourrait être appréciable.
[^] # Re: Pourquoi ne pas utiliser mod_rails ?
Posté par wilk . En réponse à la dépêche Architecture logicielle de la nouvelle version de LinuxFr.org. Évalué à 3.
NGINX n'est pas fait que pour les sites avec fort traffic, il est également particulièrement adapté aux petites configs genre serveurs virtuels. C'est peut-être de cette "mode" qu'il s'agit. C'est à dire de passer d'hébergements mutualisés avec php à des hébergement sur serveurs virtuels et des applis web en mode proxy pour utiliser autre chose que du php.
[^] # Re: Wow
Posté par wilk . En réponse à la dépêche OpenConcerto 1.0 , un nouvel ERP libre. Évalué à 1.
Les points que tu mentionnent sont spécifique à Java peut-être ? Car en python par exemple on peut très bien déployer une application web sans avoir à installer de serveur http ni apprendre plusieurs langages. OpenERP en est un exemple il me semble. Personnellement il m'arrive de déployer des applications web sous windows à l'aide d'un simple exe.
Ceci dit ça n'a pas grande importance, bravo pour le travail et sa diffusion.
[^] # Re: Bravo pour la migration !
Posté par wilk . En réponse à la dépêche Nouvelle version de LinuxFr.org. Évalué à 6.
Bruno, tu as démontré que tu pouvais faire faire beaucoup mieux que la plupart des boites spécialisées. En tant que vieux briscard de la prog, je suis impressionné et je te tire mon chapeau pour cette mise en production.
[^] # Re: Nouveaux commentaires en rouge ?
Posté par wilk . En réponse à la dépêche Architecture logicielle de la nouvelle version de LinuxFr.org. Évalué à 6.
Moi c'est le scrolling d'un commentaire nouveau à l'autre qui me donne le mal de mer...
[^] # Re: Et la doc?
Posté par wilk . En réponse à la dépêche OpenERP v6.0 est disponible. Évalué à 2.
[^] # Re: Et la doc?
Posté par wilk . En réponse à la dépêche OpenERP v6.0 est disponible. Évalué à 1.
[^] # Re: Et la doc?
Posté par wilk . En réponse à la dépêche OpenERP v6.0 est disponible. Évalué à 1.