wilk a écrit 1090 commentaires

C'est important les humains qui changent les api justement...

L'upgrade est un problème quand le rapport difficulté/gain n'est pas bon. Hors il dépend intimement du langage. En python par exemple, faire évoluer un programme est à a fois facile et apporte beaucoup. Les problèmes de compatibilités sont donc largement amortis. En revanche avec un langage beaucoup plus difficile à faire évoluer effectivement le ratio n'est pas toujours bon on a beaucoup plus intérêt à ne pas casser la compatibilité ascendante.

Concrètement les programmes en C que j'ai écris il y a 20 ans ils seront sûrement compilable sans rien changer, mais de toutes façons de fait je ne les compile plus et je ne les réutilise pas non plus. En revanche les programmes en python que j'ai écris il y a 8 ans ils ont évolués tous les ans, malgré les pertes de compatibilité je les utilise toujours.

Bref, il ne faut pas prendre en compte que la compatibilité d'un code avec le langage mais aussi la compatibilité d'un code avec soit-même ;-)

On parle d'auto-hébergement quand la personne (physique ou morale) gère elle-même le fonctionnement au jour le jour d'une infrastructure qui est dans le même bâtiment qu'elle

On dit quoi quand la personne gère elle-même le fonctionnement mais pas forcément dans le même bâtiment ? Parce que c'est quand même le sujet... Sauf erreur, Denis parle d'exim vs gmail, pas tant d'exim sur adsl vs gmail.
On peut facilement passer d'un hébergement adsl vers un hébergement dédié si on a des soucis de disponibilité matériel, sans pour autant remettre en cause ce qui nous concerne avant tout, la partir logiciel. Comme la partie logicielle est facilement redondante et cryptable le soucis des données est bien moindre.

On a bien compris, pour toi les mails ne sont plus ton affaire, tu les sous-traite à un prestataire de service, comme tu prendrai un taxi au lieu de ta voiture que tu répare toi-même. Et donc tu te fout pas mal de savoir si la voiture du taxi est réparable ou pas ni si le chauffeur note dans son carnet où tu te rends et à quelle heure. Mais dans ce cas ce qu'on ne voit pas c'est qu'est-ce que ça peut bien faire dans un journal qui traite de la mécanique à faire soit-même ?

Si on trouve que gérer ses mails soit-même est une perte de temps, on ne va perdre son temps à lire des journaux comme linux mag non plus. Lorsqu'on fait le choix de gérer ses mails généralement c'est qu'on a une bonne raison. Le temps et la difficulté sont secondaires dans ce cas.

On n'est pas bloqué et il n'y a pas de surprise vu que la version 2 est encore maintenue et pour pas mal de temps encore...
Du reste, dans la plupart des cas la migration sera triviale, le seul problème c'est les librairies et ça c'est valable pour tous les langages même s'ils ne changent pas eux-même...

La pérennité du code c'est valable dans une bulle, et dans ce cas peu importe si le langage évolue ou pas...

Il faut plutôt se demander pourquoi un logiciel serait non libre. Quel est l'intérêt d'un logiciel non libre ? Le projet GNU a démarré parce que Richard a demandé un bout de code à un copain et que pour la première fois il le lui a refusé.

Aujourd'hui on peut changer la roue de son vélo tout seul et on peut s'échanger des recettes de cuisine, si demain on m'empêche de le faire, je vais râler, est-ce que j'ai besoin de me justifier ? de m'appuyer sur une philosophie ? de savoir peser le pour et le contre de telle variation ?

Donc le mois prochain tu nous fais un gros titre "Comment se débarrasser de gmail" et t'es pardonné. Sinon on appelle nos potes anonymous et on t'inonde de mails 8-D

Tu veux dire que Denis, non seulement ne se serait pas aperçu qu'en comparant Exim à Gmail il comparait un moteur avec une carrosserie mais qu'en plus il ne se serait pas aperçu qu'il lançait un énorme troll ?
Vu la qualité de ce qu'il a déjà fait auparavant, il sait très bien ce qu'il fait, et c'est justement ça qui est choquant. Qu'un admin cède à la facilité au détriment de ses convictions, c'est humain, mais qu'il s'en vante et incite les autres à faire pareil c'est pitoyable.

Il faudrait mettre ce journal en dépêche pour faire contre-poids !

L'abattement forfaitaire de 34% identique pour tous, faut avouer ça nous arrange particulièrement (nous informaticiens)... Pour d'autres professions les frais sont généralement énormes la première année (le matériel) sans pour autant justifier d'être au réel (surtout la première année)...

A l'époque du forfait on ne jouait pas forcément la bidouille. Le truc c'est que les impôts avaient l'habitude des professions courantes mais pas des nôtres, donc il trouvait nos frais ridicules, c'est pour ça que ce n'était pas difficile de faire baisser les bénéfices.

J'ai bien vu que le CFE était calculé d'une étrange manière. Ce que je voulais rappeler c'est qu'avant ce statut celui qui ne touchait rien c'était plus proche de 3500 € que 350 € !

En tout cas aujourd'hui, AE + logiciel libre c'est vraiment le duo gagnant pour démarrer. Profitez-en !

L'AE ne paye pas ce qu'il doit justement puisqu'il n'y a aucune prise en compte des frais, le pourcentage est encore plus arbitraire... Au forfait il y avait au moins une chance.

La CFE c'est peanuts par rapport à ce qu'était le plancher de charges.

Les ptits jeunes, peut-être n'avez-vous pas connu le régime du "forfait", "c'était mieux avant"tm, voilà comment ça se passait concrètement. Une fois par an je prenais rendez-vous avec l'inspecteur des impôts, je lui montrai combien j'avais gagné dans l'année, je lui disais si j'avais fait des dépenses particulières et ensemble on définissait un bénéfice à la louche ! Mais alors une louche, une vraie, parfois le résultat frisait avec le zéro alors que je vivais (modestement) de ça !
Mais mais mais, il n'y avait pas le statut AE, du coup un plancher s'appliquait aux charges, assez dissuasif pour démarrer.

Pour tes frais oui, c'est bien de récupérer la tva...
J'ai vu sur ton blog que tu conseillais la tva simplifiée, je ne trouve pas que ça soit si simplifié que ça, il faut verser des acomptes et c'est régularisé à la fin de l'année, si on n'a pas des revenus très réguliers d'une année sur l'autre on est en déséquilibre... En revanche à la tva réelle on paye tous les mois sur les opérations du mois, c'est beaucoup plus simple, ça se rapproche même plus du statut AE, le formulaire à remplir est vraiment simple.

D'après un ami contrôleur d'assurance. Pour les autodidactes, et je pense qu'on n'est nombreux dans ce cas autour des LL, en cas de pépin important on sera toujours considéré comme fautif d'avoir fait une prestation dont on n'a pas les compétences (pas le diplôme)... Les licences libres sont bien pour ça car elles dégagent entièrement la responsabilité du développeur. Il faut facturer la "mise à disposition" et non pas la "mise en place" par ex. Pour de l'admin sys c'est plus difficile, c'est une bonne idée de faire payer le client directement au fournisseur mais ça n'est vraiment pas pratique...

Pour info l'inscription AGA il faut la faire avant fin mai de l'année en cours. Ca veut dire qu'un auto-entrepreneur susceptible de dépasser après mai à tout intérêt à s'inscrire au cas ou...

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.

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.

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 ?

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

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.

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...

Est-ce qu'il est prévu de pouvoir utiliser le webmail seul ?