La raison est que du code avec des cycles de vie complètement différents est associé à un composant.
Il n'y a que les développeurs SVN pour prétendre le contraire.
Les mêmes qui défendent leur outil en arguant que les branches ne sont pas importantes et qu'on en a pas besoin en agilité, qu'on peut contourner avec le "feature flipping" ou le "branching by abstraction", simplement pour masquer les lacunes de leur outil. Les bonnes pratiques agiles n'empechent pas d'utiliser un bon outil. qui peut le plus peut le moins.
Outre, le fait que ca améliore les performances, le découpage en dépôts permet l'approche par composant: Les composants sont donc ensuite assemblés avec des versions différentes pour former l'application. Ils sont interchangeables.
Ceci renforce aussi la structuration du code, facilite le passage de code entre différentes équipes… Les raisons ne manquent pas.
Bref, c'est une bonne pratique que les équipes sous SVN oublient parfois à leurs dépens…
Concerant ton lien:
Depuis des années nous pratiquons le "trunk based development" dans ma boîte sous Clearcase avant de passer sous Git. D'où l'intérêt de créer un dépôt par composant avec son propre cycle de vie justement.
Les branches par release ne sont intéressantes qu'à partir du moment où plusieurs releases avec des lots de fonctionnalités différentes sont développées en parallèle ou lorsque un SI contient de nombreuses application en production avec des dépendances fonctionnelles. Dans ce cas il faut pouvoir respecter des contraintes de temps lorsqu'on doit livrer des versions d'application dont d'autres dépendent et qu'on est sur leur chemin critique.
Ce cas de figure n'est pas le plus commun surtout pour de petits projets ou de petites structures. Surtout avec les méthodes agiles ou le périmètre fonctionnel évolue au lieu d'être figé pour une livraison (pas de lots en parallèle).
Le trunk based ou le branching by feature (qui permet le déploiement en continu, comme nos amis de Github ) conviennent mieux.
Mais dans tous les cas faire correspondre un dépôt a un unique composant/projet avec son propre cycle de vie est préférable.
En fait Facebook n'a pas migré de Git vers Hg mais de SVN vers Hg.
Au départ leurs code est hébergé sous SVN et ils souhaitaient continuer à fonctionner avec les caractéristiques de cet outil, tout en adoptant les avantages des DVCS. Ils ont donc toujours un dépôt central SVN mais clonent sous Git en local.
Le souci qu'ils rencontrent est un grand classique des équipes qui bossent sous SVN et qui ne veulent pas se prendre la tête à recréer un dépôt pour chaque nouveau projet. On se crée un sous-répertoire avec ses branches et tag ou alors un sous-répertoire sous trunk, branches et tags.
Quand on bosse avec SVN on fait juste un checkout du bon sous-répertoire et c'est marre.
Lorsqu'on utilise un dvcs, soit en clonant, soit en migrant l'historique à plat on rencontre plein de soucis.
Déjà, cloner un dépôt entier pour ne travailler que sur une sous-partie négligeable ça prend des plombes.
Ensuite on se retrouve à extraire tout à plat une arbo avec tous les projets qui servent à rien y compris le contenu des tags et branches.
Enfin, chaque commit fait un hash de tout le contenu alors que l'on travaille sur une portion disjointe.
Petit retour d'expérience
Pour travailler sur des sous-ensemble les DVCS ne proposent que 3 solutions.
1 N'extraire que les derniers niveaux de commits (1 niveau correspond alors à une simple snapshot de SVN)
2 Ne cloner qu'une branche
3 Ne checkouter qu'un sous-répertoire et travailler dessus.
La première solution a pour avantage d’alléger le clone. Mais elle présente l'inconvénient de travailler à la mode SVN avec les même contraintes que cet outil (pas d'historique local) et en venant de SVN, on se retrouve toujours avec l'arborescence à plat des projets et toutes les branches , tags , …
A chaque fois qu'un dev d'un projet commite et push il pollue les devs des autres projet qui doivent faire des rebase/merge fast forward pour du code qui ne les concernent pas.
La 3ème solution ne convient pas car elle ne fait que masquer les répertoires inutiles.
Déjà, elle n'est possible qu'en ligne de commande. (Les IDEs ne l'implémentent pas). ensuite ça ne résout aucun des problèmes de performances (les clones sont toujours complets, les commit sur tout le contenu, …)
Pour s'en sortir, lorsqu'on a rencontré ce pb sur un projet voici les solutions envisageables.
1- Créer un dépôt par projet et remonter l'historique.
Ceci présente 2 contraintes. L'importation est trèèèèès longue et il faut que le dépôt initial soit propre en terme d'architecture (Par exemple, si 2 projets séparés dans 2 branches distinctes ont par la suite été gérés dans une même branche, ca ne marche pas).
La démarche:
git svn clone --tags --branches svn://<mon-depot-svn> <mon-depot-git-local>
Au besoin, ajouter l'option authors-file pour faire correspondre les comptes svn avec les auteurs de commit Git. Le fichier mes-auteurs.txt doit être renseigné.
git svn clone --tags --branches --authors-file=mes-auteurs.txt svn://<mon-depot-svn> <mon-depot-git-local>
Vérifier le contenu du dépôt local et recommencer l'import si besoin. Faire le ménage (suppression/renommage des tags/branches inutiles).
Pusher ses modifs sur le serveur central
git remote add server http://git..../<mon-depot-git-central>
git push --all server
git push --tags server
2 - Utiliser le clone par branche (point 2)
D'abord Migrer l'historique SVN tel quel dans Git dans un dépôt legacy. Créer un autre dépôt propre puis créer une branche par branche active de projet dans laquelle on recopie la dernière révision de la branche active du projet. On expurge tous les répertoires des autres projets. On commit et on pushe sur le dépôt central.
Ensuite il suffit de cloner les bonnes branches pour ses besoins.
Ceci reste tout de même contraignant par rapport à la façon de travailler avec SVN puisqu’il faut manipuler les branches avec des conventions de nommage. Ce n'est pas dans les habitudes des développeurs venant de SVN.
Cette solution est à appliquer lorsque le code est trop imbriqué (comme décrit plus haut). Pour les modules biens disjoints, on peut appliquer la première solution pour les isoler dans un dépôt (et utiliser submodule si besoin)
Voilà.
Encore une fois une bonne architecture et une bonne gestion de conf peuvent aider à sauver des BB phoques.
Nos petits amis de FB, n'ont visiblement pas envie de se prendre la tête avec cette migration (ou ont une archi toute pourite ???). Ils préfèrent filer un coup de main au projet Hg (parce que c'est plus simple pour eux AMHA, pas parce qu'il préfèrent Hg à l'usage, j'imagine que c'est plus facile de déployer un plugin en interne que de convaincre une communauté) en optimisant le point 3. Notamment ils font en sorte que les commits ne s'applique sur des hash des fichiers modifiés et non sur tout le contenu et ensuite ils optimisent le cache pour ne travailler que sur le sous-graphe connexe plutôt que sur tout l'historique.
Tant mieux pour ce projet libre. Mais pas sûr qu'ils échappent à terme à ne plus travailler comme des gorets (un vendredi on peut se permettre un petit troll) et à migrer.
Ah !
Et dans
"
La participation des entreprises aux logiciels libres touche des domaines différents aux sciences économiques et sciences "
Rien ne te choque.
J aurais écrit :La participation des entreprises aux logiciels libres touche des domaines différents comme les sciences économiques ou les sciences sociales.
Surtout, ce qui "nous" interloque en général (Moi et Moi) c est surtout que toutes ces pompeuses productions individuelles semblent émaner de plusieurs personnes. Un chercheur vaudrait il plusieurs grouillots?
La modestie n etouffe pas les doctorants.
Cette condescendance nuit a la fluidité du discours.
N est il pas , Charles Henri ?
En tout cas ça fait tache avec des fautes grammaticales grossières.
On y retrouve une vision assez partagée ici.
- Oui au droit d'auteur, non aux brevets de tout ordre.
- L'invention ou la découverte simultanée est permise par le droit d'auteur tout en évitant le plagiat
- La concurrence stimule l'effort de recherche alors que les brevets endiguent le progrès en décourageant les concurrents et en permettant au détenteur de se reposer sur ses lauriers
- Quels critères pour évaluer le bon investissement en recherche
- Les initiatives communautaires non exclusives encouragées,
…
Clairement les brevets ne sont pas liés intrinsèquement au libéralisme.
Seul point qui mérite débat et qu'un interlocuteur avait abordé ici-même (sans réponse d'ailleurs)
: Le domaine public
J'avoue que j'ai un peu du mal à me convaincre que le marché ne vas pas nous faire acheter de l'air en bouteille un jour alors qu'un peu de régulation maintenant changerait cette destinée, mais bon …
Rien qu'en lisant le résumé on sent le parti pris:
Reprenant l'idéal cybernétique de libre circulation de l'information, l'utopie du logiciel libre se présente comme une contestation de la vision néolibérale de la propriété intellectuelle,
Quelle est la définition du terme néoliberal hormis la définition consensuelle de personnes auto-convaincues que le libéralisme est forcément néfaste et emploie ce terme péjoratif comme d'autre parle de logiciels "privateurs"
La propriété intellectuelle est-elle inhérente au "néoliberalisme" comme le sous entend l'auteur ?
Ceci pose une fois de plus le questionnement du libéralisme vs socialisme.
De quel droit peut-on me spolier de ma propriété privée, droit naturel par excellence au nom du soi-disant intérêt commun.
En voilà de la coercition ?
Mis à part une prise de conscience urgente de l'intérêt de coopérer, de mettre en avant les efforts communautaires, je ne vois pas comment y parviendrait. Seulement le moteur de l'innovation est l'argent. Comment inverser cette tendance ?
A l'heure ou OSM tente de combler son retard par rapport à Google Maps, Waze qui s'appuie sur les communautés est une initiative privée. Encore un retard à l'allumage. Idem pour identi.ca et autre réseaux sociaux libres.
Il y aura toujours un décalage.
Et en confiant les clés à des intérêts privés qui basent leur avenir sur l'organisation de la rareté, je n'ai pas le sentiment qu'on en prenne le chemin.
Ce qui change c'est l'accessibilité.
Les avancées d'ordre privé bénéficient rarement à tous sans contrepartie.
Ce que j'adore en fait c'est qu'ici on a 2 poids 2 mesures.
Tout le monde flagelle en coeur Bill Gates et sa fondation mais lorsque Google agit de même il bénéficie d'un aura… Etrange !!!
Tu viens donc de montrer ce que je disais.
Ton argent comme les donnees que chacun donnees a Google font un business model … et donc la gratuite n'existe pas.
TON argument est donc foireux.
CQFD.
Merci mr je sais tout.
Au fait n'oublies pas de faire de la pub pour cette banque qui ne se paie que sur l'argent qui traine.
Ah tu ne paies pas de frais de gestion pour ta banque toi ?
Moi si !
tout comme la gratuité n'existe pas avec Google ou FB qui se remnuère avec tes informations,
la gratuité des transactions n'existe pas. Tu la paies avec ton compte en banque.
On s'en fout !
On s'achète une grosse bagnole, on vient dans les ville exprès pour y faire des bouchons et on repart tranquillement pendant que tes gamins doivent rester enfermés.
Alors profite et respire bien le gaz d'échappement. J’accélérerai un peu au ralenti ce soir pour te dédicacer une petite bouffée.
Ceci me donne l'occasion de faire un peu de pub pour un site de la fondation wikimedia que j'apprécie:
Wikisources
L'objectif est de mettre en ligne toutes les oeuvres passées dans domaine public mais à la différence d'autre site "publics" l'initiative est collaborative.
Il permet d'OCRiser les livres puis de les corriger et les relire en ligne.
Chacune peut s'y mettre en relisant une page.
Inutile un projet est un regroupement de sous-tâches et donc une tâche.
C'est très consistant comme ça.
Il faut juste a veiller à ce que le statut d'un projet ne soit pas éditable s'il contient des tâched mais que ce soit les tâches en dessous qui fassent évoluer son statut (Sauf peut-être pour clore un projet qu'on abandonne ou tout passer a un autre état).
C'est vraiment très chouette en fait.
Ca fait longtemps que je recherche une web app de ce type en python.
Autre suggestion pour les contacts, peut-être des champs spécifiques (mail , tel, jid, …)
Et pour le dashboard les dernières actions n'apportent pas grand chose AMHA mais une vue des prochains événements serait un plus.
J'ai compris et ca confirme ce que je disais.
en passant en status todo je le retrouve.
C'est un document qui apparait comme action.
Il te suffit simplement de les renommer et ca devient très intuitif.
C'est un très bon boulot en tout cas.
Non juste que pour moi une action de todolist ce n'est pas un document.
Mais vu qu'on peut les éditer en ligne je comprends mieux.
C'est assez déconcertant en fait d'autant qu"on peut lire des fichier à un "Document"
J'aurais plus vu les dossiers comme des projets les "Document" comme des actions.
Je n'ai d'ailleurs pas réussi a voir des actions dans le dashboard.
Sinon, il semble que lorsque tu crées un evt au jour même ca plante mais c'est très propre autrement
[^] # Re: Mensongeries
Posté par El Titi . En réponse au journal "Scaling Mercurial at Facebook". Évalué à 2.
La raison est que du code avec des cycles de vie complètement différents est associé à un composant.
Il n'y a que les développeurs SVN pour prétendre le contraire.
Les mêmes qui défendent leur outil en arguant que les branches ne sont pas importantes et qu'on en a pas besoin en agilité, qu'on peut contourner avec le "feature flipping" ou le "branching by abstraction", simplement pour masquer les lacunes de leur outil. Les bonnes pratiques agiles n'empechent pas d'utiliser un bon outil. qui peut le plus peut le moins.
Outre, le fait que ca améliore les performances, le découpage en dépôts permet l'approche par composant: Les composants sont donc ensuite assemblés avec des versions différentes pour former l'application. Ils sont interchangeables.
Ceci renforce aussi la structuration du code, facilite le passage de code entre différentes équipes… Les raisons ne manquent pas.
Bref, c'est une bonne pratique que les équipes sous SVN oublient parfois à leurs dépens…
Concerant ton lien:
Depuis des années nous pratiquons le "trunk based development" dans ma boîte sous Clearcase avant de passer sous Git. D'où l'intérêt de créer un dépôt par composant avec son propre cycle de vie justement.
Les branches par release ne sont intéressantes qu'à partir du moment où plusieurs releases avec des lots de fonctionnalités différentes sont développées en parallèle ou lorsque un SI contient de nombreuses application en production avec des dépendances fonctionnelles. Dans ce cas il faut pouvoir respecter des contraintes de temps lorsqu'on doit livrer des versions d'application dont d'autres dépendent et qu'on est sur leur chemin critique.
Ce cas de figure n'est pas le plus commun surtout pour de petits projets ou de petites structures. Surtout avec les méthodes agiles ou le périmètre fonctionnel évolue au lieu d'être figé pour une livraison (pas de lots en parallèle).
Le trunk based ou le branching by feature (qui permet le déploiement en continu, comme nos amis de Github ) conviennent mieux.
Mais dans tous les cas faire correspondre un dépôt a un unique composant/projet avec son propre cycle de vie est préférable.
# Mensongeries
Posté par El Titi . En réponse au journal "Scaling Mercurial at Facebook". Évalué à 3. Dernière modification le 10 janvier 2014 à 10:56.
En fait Facebook n'a pas migré de Git vers Hg mais de SVN vers Hg.
Au départ leurs code est hébergé sous SVN et ils souhaitaient continuer à fonctionner avec les caractéristiques de cet outil, tout en adoptant les avantages des DVCS. Ils ont donc toujours un dépôt central SVN mais clonent sous Git en local.
Le souci qu'ils rencontrent est un grand classique des équipes qui bossent sous SVN et qui ne veulent pas se prendre la tête à recréer un dépôt pour chaque nouveau projet. On se crée un sous-répertoire avec ses branches et tag ou alors un sous-répertoire sous trunk, branches et tags.
Quand on bosse avec SVN on fait juste un checkout du bon sous-répertoire et c'est marre.
Lorsqu'on utilise un dvcs, soit en clonant, soit en migrant l'historique à plat on rencontre plein de soucis.
Déjà, cloner un dépôt entier pour ne travailler que sur une sous-partie négligeable ça prend des plombes.
Ensuite on se retrouve à extraire tout à plat une arbo avec tous les projets qui servent à rien y compris le contenu des tags et branches.
Enfin, chaque commit fait un hash de tout le contenu alors que l'on travaille sur une portion disjointe.
Petit retour d'expérience
Pour travailler sur des sous-ensemble les DVCS ne proposent que 3 solutions.
1 N'extraire que les derniers niveaux de commits (1 niveau correspond alors à une simple snapshot de SVN)
2 Ne cloner qu'une branche
3 Ne checkouter qu'un sous-répertoire et travailler dessus.
La première solution a pour avantage d’alléger le clone. Mais elle présente l'inconvénient de travailler à la mode SVN avec les même contraintes que cet outil (pas d'historique local) et en venant de SVN, on se retrouve toujours avec l'arborescence à plat des projets et toutes les branches , tags , …
A chaque fois qu'un dev d'un projet commite et push il pollue les devs des autres projet qui doivent faire des rebase/merge fast forward pour du code qui ne les concernent pas.
La 3ème solution ne convient pas car elle ne fait que masquer les répertoires inutiles.
Déjà, elle n'est possible qu'en ligne de commande. (Les IDEs ne l'implémentent pas). ensuite ça ne résout aucun des problèmes de performances (les clones sont toujours complets, les commit sur tout le contenu, …)
Pour s'en sortir, lorsqu'on a rencontré ce pb sur un projet voici les solutions envisageables.
1- Créer un dépôt par projet et remonter l'historique.
Ceci présente 2 contraintes. L'importation est trèèèèès longue et il faut que le dépôt initial soit propre en terme d'architecture (Par exemple, si 2 projets séparés dans 2 branches distinctes ont par la suite été gérés dans une même branche, ca ne marche pas).
La démarche:
2 - Utiliser le clone par branche (point 2)
D'abord Migrer l'historique SVN tel quel dans Git dans un dépôt legacy. Créer un autre dépôt propre puis créer une branche par branche active de projet dans laquelle on recopie la dernière révision de la branche active du projet. On expurge tous les répertoires des autres projets. On commit et on pushe sur le dépôt central.
Ensuite il suffit de cloner les bonnes branches pour ses besoins.
Ceci reste tout de même contraignant par rapport à la façon de travailler avec SVN puisqu’il faut manipuler les branches avec des conventions de nommage. Ce n'est pas dans les habitudes des développeurs venant de SVN.
Cette solution est à appliquer lorsque le code est trop imbriqué (comme décrit plus haut). Pour les modules biens disjoints, on peut appliquer la première solution pour les isoler dans un dépôt (et utiliser submodule si besoin)
Voilà.
Encore une fois une bonne architecture et une bonne gestion de conf peuvent aider à sauver des BB phoques.
Nos petits amis de FB, n'ont visiblement pas envie de se prendre la tête avec cette migration (ou ont une archi toute pourite ???). Ils préfèrent filer un coup de main au projet Hg (parce que c'est plus simple pour eux AMHA, pas parce qu'il préfèrent Hg à l'usage, j'imagine que c'est plus facile de déployer un plugin en interne que de convaincre une communauté) en optimisant le point 3. Notamment ils font en sorte que les commits ne s'applique sur des hash des fichiers modifiés et non sur tout le contenu et ensuite ils optimisent le cache pour ne travailler que sur le sous-graphe connexe plutôt que sur tout l'historique.
Tant mieux pour ce projet libre. Mais pas sûr qu'ils échappent à terme à ne plus travailler comme des gorets (un vendredi on peut se permettre un petit troll) et à migrer.
[^] # Re: Médiocrité de l'expression
Posté par El Titi . En réponse à la dépêche Petite sélection de mémoires publiés après 2010. Évalué à 3.
Ah !
Et dans
"
La participation des entreprises aux logiciels libres touche des domaines différents aux sciences économiques et sciences "
Rien ne te choque.
J aurais écrit :La participation des entreprises aux logiciels libres touche des domaines différents comme les sciences économiques ou les sciences sociales.
Surtout, ce qui "nous" interloque en général (Moi et Moi) c est surtout que toutes ces pompeuses productions individuelles semblent émaner de plusieurs personnes. Un chercheur vaudrait il plusieurs grouillots?
La modestie n etouffe pas les doctorants.
Cette condescendance nuit a la fluidité du discours.
N est il pas , Charles Henri ?
En tout cas ça fait tache avec des fautes grammaticales grossières.
[^] # Re: Merci
Posté par El Titi . En réponse à la dépêche Petite sélection de mémoires publiés après 2010. Évalué à 3.
Relisez aussi la position de Rothbard, un libertarien qui fait autorité:
http://lemennicier.bwm-mediasoft.com/displayArticle.php?articleId=197
On y retrouve une vision assez partagée ici.
- Oui au droit d'auteur, non aux brevets de tout ordre.
- L'invention ou la découverte simultanée est permise par le droit d'auteur tout en évitant le plagiat
- La concurrence stimule l'effort de recherche alors que les brevets endiguent le progrès en décourageant les concurrents et en permettant au détenteur de se reposer sur ses lauriers
- Quels critères pour évaluer le bon investissement en recherche
- Les initiatives communautaires non exclusives encouragées,
…
Clairement les brevets ne sont pas liés intrinsèquement au libéralisme.
Seul point qui mérite débat et qu'un interlocuteur avait abordé ici-même (sans réponse d'ailleurs)
: Le domaine public
J'avoue que j'ai un peu du mal à me convaincre que le marché ne vas pas nous faire acheter de l'air en bouteille un jour alors qu'un peu de régulation maintenant changerait cette destinée, mais bon …
[^] # Re: Merci
Posté par El Titi . En réponse à la dépêche Petite sélection de mémoires publiés après 2010. Évalué à 7.
Pas moi par contre.
Rien qu'en lisant le résumé on sent le parti pris:
Quelle est la définition du terme néoliberal hormis la définition consensuelle de personnes auto-convaincues que le libéralisme est forcément néfaste et emploie ce terme péjoratif comme d'autre parle de logiciels "privateurs"
La propriété intellectuelle est-elle inhérente au "néoliberalisme" comme le sous entend l'auteur ?
Lisez cet excellent article de cet autre auteur au sujet de la PI:
http://lemennicier.bwm-mediasoft.com/displayArticle.php?articleId=125
et ce papier:
http://www.euro92.com/acrob/lemennicierbrevets.pdf
Attention on a affaire à un anarcho-capitaliste:
http://fr.wikipedia.org/wiki/Bertrand_Lemennicier
[^] # Re: tag « Zenitram »
Posté par El Titi . En réponse au journal Le Codec VP9 reçoit le soutien de l'industrie.. Évalué à 4.
Je viens de créer un tag "moi".
N'hésite pas à nous plébisciter.
# Question con
Posté par El Titi . En réponse au journal Un interface en ligne de commande pour votre cloud personnel Cozy. Évalué à 5.
Une API REST combinée à du curl, ça le fait pas ?
[^] # Re: Rien de nouveau à l'horizon
Posté par El Titi . En réponse au journal Google Robotics. Évalué à 2.
Et les pauvres mangeront du soleil vert
[^] # Re: Rien de nouveau à l'horizon
Posté par El Titi . En réponse au journal Google Robotics. Évalué à 9.
Tu as oublié l'épice !!!
[^] # Re: Rien de nouveau à l'horizon
Posté par El Titi . En réponse au journal Google Robotics. Évalué à 5.
Mon message décrivait la pensée des libéraux.
Je n'ai pas précisé que j'y souscrivais.
[^] # Re: Rien de nouveau à l'horizon
Posté par El Titi . En réponse au journal Google Robotics. Évalué à 2.
Ceci pose une fois de plus le questionnement du libéralisme vs socialisme.
De quel droit peut-on me spolier de ma propriété privée, droit naturel par excellence au nom du soi-disant intérêt commun.
En voilà de la coercition ?
Mis à part une prise de conscience urgente de l'intérêt de coopérer, de mettre en avant les efforts communautaires, je ne vois pas comment y parviendrait. Seulement le moteur de l'innovation est l'argent. Comment inverser cette tendance ?
A l'heure ou OSM tente de combler son retard par rapport à Google Maps, Waze qui s'appuie sur les communautés est une initiative privée. Encore un retard à l'allumage. Idem pour identi.ca et autre réseaux sociaux libres.
Il y aura toujours un décalage.
Dire qu'on n'est même pas vendredi.
[^] # Re: PEBKAC
Posté par El Titi . En réponse au journal Informatique de confiance et Android. Évalué à 1.
Il semble que laisser le contrôle à l'utilisateur ne soit pas du goût de Big Brother, on se demande pourquoi ?
http://www.lesmobiles.com/actualite/12607-app-ops-retire-d-android-4-4-2-pourquoi-cette-decision-est-elle-discutable.html
[^] # Re: Paranoïa ou stupidité?
Posté par El Titi . En réponse au journal Google Robotics. Évalué à 2.
un**e** aura … houps
[^] # Re: Rien de nouveau à l'horizon
Posté par El Titi . En réponse au journal Google Robotics. Évalué à 7.
Et en confiant les clés à des intérêts privés qui basent leur avenir sur l'organisation de la rareté, je n'ai pas le sentiment qu'on en prenne le chemin.
[^] # Re: Paranoïa ou stupidité?
Posté par El Titi . En réponse au journal Google Robotics. Évalué à 8.
Ce qui change c'est l'accessibilité.
Les avancées d'ordre privé bénéficient rarement à tous sans contrepartie.
Ce que j'adore en fait c'est qu'ici on a 2 poids 2 mesures.
Tout le monde flagelle en coeur Bill Gates et sa fondation mais lorsque Google agit de même il bénéficie d'un aura… Etrange !!!
[^] # Re: Gné
Posté par El Titi . En réponse au journal Paylib va enfin remplacer paypal !. Évalué à -3.
Tu viens donc de montrer ce que je disais.
Ton argent comme les donnees que chacun donnees a Google font un business model … et donc la gratuite n'existe pas.
TON argument est donc foireux.
CQFD.
Merci mr je sais tout.
Au fait n'oublies pas de faire de la pub pour cette banque qui ne se paie que sur l'argent qui traine.
[^] # Re: Gné
Posté par El Titi . En réponse au journal Paylib va enfin remplacer paypal !. Évalué à 4.
Ah tu ne paies pas de frais de gestion pour ta banque toi ?
Moi si !
tout comme la gratuité n'existe pas avec Google ou FB qui se remnuère avec tes informations,
la gratuité des transactions n'existe pas. Tu la paies avec ton compte en banque.
[^] # Re: mouais
Posté par El Titi . En réponse au journal Bruce Perens contre le chiffrement systématique. Évalué à 3.
On s'en fout !
On s'achète une grosse bagnole, on vient dans les ville exprès pour y faire des bouchons et on repart tranquillement pendant que tes gamins doivent rester enfermés.
Alors profite et respire bien le gaz d'échappement. J’accélérerai un peu au ralenti ce soir pour te dédicacer une petite bouffée.
[^] # Re: Publicité bactérienne
Posté par El Titi . En réponse au journal Quand Microsoft se paie la tête des Chromebooks.... Évalué à 2.
Faut au moins être ambidextre pour faire ça, non ?
[^] # Re: Wikisources
Posté par El Titi . En réponse au journal contenus epub. Évalué à 2.
Ebooks gratuits est pas mal non plus.
Ce sont des livres du domaine public mais là c'est une personne qui s'en occupe seul.
http://www.ebooksgratuits.com/
# Wikisources
Posté par El Titi . En réponse au journal contenus epub. Évalué à 2.
Ceci me donne l'occasion de faire un peu de pub pour un site de la fondation wikimedia que j'apprécie:
Wikisources
L'objectif est de mettre en ligne toutes les oeuvres passées dans domaine public mais à la différence d'autre site "publics" l'initiative est collaborative.
Il permet d'OCRiser les livres puis de les corriger et les relire en ligne.
Chacune peut s'y mettre en relisant une page.
Il y a moultes livres télechargeable en epub ici:
http://fr.wikisource.org/wiki/Epub
Bonne pioche
# Et sinon
Posté par El Titi . En réponse au journal pod : un outil pour suivre et gérer des tâches et documents. Évalué à 1.
POD c'est aussi un groupe qui déchire
[^] # Re: Intéressant mais
Posté par El Titi . En réponse au journal pod : un outil pour suivre et gérer des tâches et documents. Évalué à 2. Dernière modification le 21 novembre 2013 à 17:48.
Inutile un projet est un regroupement de sous-tâches et donc une tâche.
C'est très consistant comme ça.
Il faut juste a veiller à ce que le statut d'un projet ne soit pas éditable s'il contient des tâched mais que ce soit les tâches en dessous qui fassent évoluer son statut (Sauf peut-être pour clore un projet qu'on abandonne ou tout passer a un autre état).
C'est vraiment très chouette en fait.
Ca fait longtemps que je recherche une web app de ce type en python.
Autre suggestion pour les contacts, peut-être des champs spécifiques (mail , tel, jid, …)
Et pour le dashboard les dernières actions n'apportent pas grand chose AMHA mais une vue des prochains événements serait un plus.
Encore toutes mes félicitations !
[^] # Re: Intéressant mais
Posté par El Titi . En réponse au journal pod : un outil pour suivre et gérer des tâches et documents. Évalué à 2.
J'ai compris et ca confirme ce que je disais.
en passant en status todo je le retrouve.
C'est un document qui apparait comme action.
Il te suffit simplement de les renommer et ca devient très intuitif.
C'est un très bon boulot en tout cas.
Une déclinaison GTD et tu as un truc du tonnerre
[^] # Re: Intéressant mais
Posté par El Titi . En réponse au journal pod : un outil pour suivre et gérer des tâches et documents. Évalué à 2.
Non juste que pour moi une action de todolist ce n'est pas un document.
Mais vu qu'on peut les éditer en ligne je comprends mieux.
C'est assez déconcertant en fait d'autant qu"on peut lire des fichier à un "Document"
J'aurais plus vu les dossiers comme des projets les "Document" comme des actions.
Je n'ai d'ailleurs pas réussi a voir des actions dans le dashboard.
Sinon, il semble que lorsque tu crées un evt au jour même ca plante mais c'est très propre autrement