Je réfléchis à cette proposition et si ça intéresse quelqu'un j'envisage une série de journaux pour présenter différents workflows avec les tenants et aboutissants de ces choix.
Ce serait super intéressant ! :)
Je verrais bien une commande intermédiaire qui te permet d'enregistrer ton travail en local régulièrement:
Big data fournit une plateforme centralisée pour accéder en masse à des données personnelles : la gesttapo n'aurait pas réver mieux.
Non. Le big data est un ensemble de techniques permettant de manipuler une quantité arbitraire de données.
Tu cherche à l'associé avec l'un des usages qui en est fait, mais c'est une généralisation très malheureuse.
Le big data n'a rien avoir avec la collecte de données personnelles. Quand un super marché prends tous ses tickets de caisse les fou dans une base et fait du machine learning, ça n'est en rien de la collecte de données personnelles. Pourtant si c'est Carrefour ou Wallmart qui le fait ils vont avoir des problématique adressés par le big data. Si tu es une banque et que tu dois pour lutter contre le blanchiement d'argent pouvoir fournir une traçabilité complète de toutes les comptes, tu va devoir faire du big data. Si tu as un tas de capteurs qui t'envoient des données de manière régulière ou continue, tu fera du big data.
Le big data ne sont que des techniques pour scaler sur ton volume de données, rien de plus.
C'est un outil à la collecte des données au même titre qu'internet.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Je ne suis pas d'accord avec Debian :)
Autant clairement la GFDL est une erreur dans la nature, autant je ne trouve pas qu'il soit judicieux d'utiliser une licence logiciel pour une documentation. Il existe des licences plus spécifiques qui sont plus compréhensible pour les potentiels contributeurs à une documentation. Bien sûr je pense aux CC qui font office de standard de fait pour tout ce qui n'est pas à proprement dis exécutable (j'ai assez peur de la transposition qui peut être fait devant une coure de justice de code source ou d'exécution pour de la documentation). Après évidement une licence type RABL n'est pas plus logiciel qu'autre chose ;)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Il faut que je me penche là dessus, parce que je ne suis pas non plus satisfait de ma solution…
J'aimerais personnellement avoir de l'envoie scp, https, bitorrent ou synthings et de la récupération bitorrent ou https avec une interface d'admin pour gérer tout ça.
bt est super pratique pour la manipulation de très gros fichiers (genre 5Gio et plus) pour la performance, mais aussi pour la gestion de la bande passante et pour la reprise du transfert.
Ce serait génial, mais ce ne sera de toute manière pas aussi pratique à mettre en place.
Merci du partage ! :)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Oui et c'est normal car ce sont des techno et pas des fonctionnalités. Passer des années à mûrir des fonctionnalités ce serait extrêmement préjudiciable. Ça la même déjà était à l'époque de Firefox 4.
Hello, le truc d'authentification, pocket : des fonctionnalités sorties du chapeau qui débarquent dans Firefox sans répondre à un besoin, ni perdurer un fois qu’une base utilisateur commence à exister (et que le besoin s’est donc mis à exister), dans une espèce de course à la différenciation avec les autres butineurs qui semble aussi désespérée qu’irréfléchie. Mozilla est encore capable d’innover, mais le plan de route de Firefox ressemble à la trajectoire de course d’une poule décapitée.
Ou alors comme les rageux ne viennent pas faire de retour sur les canals nigthly ou beta et ne sont pas non plus inscrit à la liste UX de Firefox. Ils n'ont aucun autre moyen que leur dont de voyance pour savoir ce qui va te plaire ou non. Il y a un moment où il faut comprendre que :
soit tu choisi de t'investir parce que tu te sens concerné
soit ça va se faire sans toi et tu va subir
Utiliser un firefox plus à jour que stable pour faire remonter ce qui te plaît ou pas. Ça n'est pas un investissement important. S'inscrire à la liste UX non plus.
Se plaindre que les décisions ne sont pas prises de manière communautaire et ne rien faire pour tenter de s'inscrire dans la communauté c'est ridicule. C'est du logiciel libre, ça implique certaines choses au cas où certains n'auraient pas compris (voir la méritocratie dans le LL pour ceux qui ne savent pas de quoi il s'agit).
Innover c’est bien, mais gaver Firefox d’essais infructueux ce n’est pas de l’innovation, par contre c’est dommageable pour l’image de Mozilla et ne ramènera pas d’utilisateurs, au contraire.
On annonce en grande pompe des produits qui suscitent de l'espoir et on tue le projets quelques mois après, ça donne une mauvaise image aurpès des utilisateurs.
Non. c'est l'incapacité à innover qui fait ça. Quand une organisation n'a plus le droit à l'erreur, qu'elle ne peut plus essayer quelque chose sans devoir le maintenir des années, alors c'est que c'est très très mal parti. Personnellement je suis très content de voir Mozilla essayer des choses certaines ratées (Hello ou le truc d'authentification par exemple) d'autres plutôt réussi (Servo, Rust). C'est le fait de se perdre à maintenir des projets pour la beauté du geste qui risquerait de tuer Mozilla.
Après on peut leur reprocher leur choix, mais que ce soit Mozilla, Google ou je ne sais qui. C'est plutôt bon signe pour eux de voir qu'ils sont capable d'arrêter quelque chose qui ne rempli pas leurs objectifs (oui je sais SQL est resté en gestation pendant 8 ans avant de sortir de chez IBM, un peu comme Rust en fait…).
S'il y a une chose qui me paraît bonne de ce qu'on m'a dit de la culture américaine et qui la sépare de nous, c'est cette capacité à voir de manière positive le fait d'avoir essayer même lors d'échec. Ça permet de ne pas rester tétanisé par la peur de l'échec.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Mais il n'y a pas 50 façons de faire du dev avec git, il faudrait juste 3 ou 4 set de commande en fonction de la méthode choisie.
AMHA il y en a plus. Il est tout à fait possible de créer un gitflow-like pour ton workflow. gitflow a précisément était créé pour ça : simplifier une méthode de développement.
Je pense que c'est une bonne chose d'avoir un outil agnostique puis d'avoir des plugins/surcouche « opinionated » comme disent les anglosaxons.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Pourquoi as-tu besoin de croiser tes messages (les relations d'ordres entre les messages UML sont toujours partielles, selon la norme) ?
Comme ça je dirais que c'est pratique quand tu veut décrire un scénario dans un système P2P avec des évènements qui arrivent sur 2 nœuds simultanément.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Le Branching by Abstraction je ne crois pas que ce soit autre chose qu'une vue de l'esprit. Je n'ai jamais vu des gens en faire pour de vrai. Je pense que c'est trop complexe pour véritablement être mis en place.
Je suis tristesse de l'avoir mis en place plusieurs fois avec succès alors :-(
C'est peut être mal perçu. Je suis au contraire content que ça existe. Je suis friand de retours d’expérience, même si IRL je n'ai que rarement mon mot à dire là dessus. C'est au moins pour l'esprit ;)
L'un des gros avantages (qui est commun aux features branches et qui contredit _ il n'y a pas de différence notable entre un mec qui développe dans son workspace sans soumettre son code et sans mettre à jour sa base de code et le feature branche_ ) est que le code de la nouvelle feature, bien que partiellement désactivé en prod, était dans la CI, les tests se jouaient dessus en permanence, tout le monde utilisait la nouvelle abstraction.
Dans mon monde on en est pas là (sic), on à pas d'IC sur les branches et on a pas suffisamment de tests d'intégration…
Merci de ton retour :)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Par ailleurs, je parlais de son comportant une fois qu'il est installé, car une fois qu'il est installé il vit dans le processus de boot. C'est ce qu'empêche Secure Boot.
Bof globalement il vit là où il en a envie. Ça marche avec une chaîne d'outils signée. L'UEFI accepte de lancer uniquement un bootloader signé qui n'accepte de lancer qu'un noyau signé qui n'accepte de lancer que des binaires signés. Et tout ça se base sur l'idée que tu passe par un provider de logiciel qui va signer tout tes logiciels pour toi. C'est ce que fait Apple sur iPhone si j'ai bien compris. Je ne connais pas de machines de bureau quelque soit l'OS qui fasse quelque chose d'aussi complet. Donc ton malaware, s'il ne peux pas remplacer le bootloader, il remplacera le noyau ou se chargera dedans, au pire il remplacera ton système d'init. En terme de puissance néfaste c'est la même chose, il n'y a qu'en terme de facilité à le détruire que les choses sont un peu différentes.
Mais du coup les clients, ils refusent linux parce qu'il n'y a pas secure boot ? Ils sont aussi du genre à refuser parce qu'ils trouvent que l'implémentation de malloc(3) dans la libc n'est pas à leur goût ou bien ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Cependant, je ne vois pas beaucoup le navigateur/OS pousser les protocoles peer to peer pour le moment et pourtant, pour la diffusion de certain flux comme des télé ou des radios, c'est pas si mal pour l’infrastructure.
T'es pas le premier à qui j'ai envie de faire la remarque. Le P2P c'est bien pour les débit, pas pour la latence. Ce n'est pas le truc optimal qui va marcher pour tout. Du streaming, des petits fichiers etc ça match pas très bien (ça vient du protocole et de ton ADSL).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Justement quand je lis son poste « SemanticConflict » que tu as cité et que je lis sa première phrase :
Those who hear my colleagues and I talk about FeatureBranch know that we're not big fans of that pattern. An important part of our objection is the observation that branching is easy, but merging is hard.
C'est pour moi exactement l'inverse, si quelque chose est difficile, il faut le faire plus souvent. Si on ne fait pas quelque chose parce qu'elle est difficile, elle restera forcément difficile. Alors que si tu te casse les dents dessus 2, 3, 20 ou 30 fois. Tu va mécaniquement t'améliorer et trouver des solutions pour résoudre tes problèmes.
Pour le feature branch, il n'y a pas de différence notable entre un mec qui développe dans son workspace sans soumettre son code et sans mettre à jour sa base de code (ce que je vois tous les jours) et le feature branche. C'est juste que ce dernier est nommé et est plus correctement outillé. Encore une fois plus ton équipe est petite et mieux ça se passe (les merges peuvent être fait à 2). Personnellement je n'ai jamais trouvé que les merges soient véritablement difficile quand tu n'a pas des gens qui passent des semaines sans faire de merge/rebase.
Le Branching by Abstraction je ne crois pas que ce soit autre chose qu'une vue de l'esprit. Je n'ai jamais vu des gens en faire pour de vrai. Je pense que c'est trop complexe pour véritablement être mis en place.
Au cas où tu émettes quelques doutes sur la crédibilité du personnage, je t'invite à jeter un oeil à la liste des signataires du manifeste agile
C'est un peu de l'argumentation d'autorité ça ;) M. Fowler est intéressant, mais c'est pas mal d'aller voir ce qui se fait ailleurs (surtout qu'il y a pleins de gens qui parlent de leur expérience sur ce genre de sujets).
Le niveau ultime est le continuous deployment. Le déploiement est automatisé lors de chaque build. C'est l’achèvement du DevOps (nous sommes loin de ce niveau de maturité hélas).
C'est surtout pas toujours faisable d'un point de vu non technique (si le déploiement consiste à aller en centrale nucléaire installer ta nouvelle version de logiciel qui met un bout de matos en indispo, pour te cité un cas que je connais et qui est extrême).
Mais je ne suis pas d'accord sur le fait que ta stratégie de branching va jouer sur ta stratégie de release/déploiement. Encore une fois les furets ne suivent pas du tout ton idée et ils font autant de déploiement qu'ils le souhaitent (de tête plusieurs par semaine, un déploiement se fait en ~ 2h). D'ailleurs je ne me souviens pas d'avoir entendu Sacha Labourey (si tu veux que je cite une autre référence) parler de stratégie de branchement pour parler de continus deployment.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
D’expérience, là où j'ai travaillé, personne n'était assez mature pour faire ça sans complètement exploser la complexité du code et sans se perdre dans toutes les fonctionnalités.
L'agilité ça consiste à discuter au plus tôt sur les questions qui pourraient poser problème. La base de l'agilité c'est l'intégration continue. Tout ce qui y contrevient est malvenu.
Ouai bof, ça n'est pas vraiment un problème. Faut rebaser fréquemment. Sur des petites équipes ça ne pose aucun problème. Ton intégration continue elle doit surtout être toujours verte, tu dois pouvoir livrer à tout moment, à la fréquence qui te semble opportune et pas à la fréquence que tu es capable de faire. Donc non tu ne peux pas accepter qu'un gars commit une erreur ou un truc qui a un effet de bord indésiré. Si tu veux, tu peux contraindre ton IC à faire un rebase fréquent (si la branche à lancer n'est pas assez à jour la passer en erreur).
Ce n'est qu'au moment où vous intégrez que les problèmes arrivent et notamment le big bang merge, les conflits sémantiques et c'est souvent le plus mauvais moment… peu avant la fin du sprint.
Ça n'est pas une vérité générale. J'ai vu une conférence des furets. Ils n'ont pas de master et font systématiquement du big bang merge comme tu dis. Ils ont créé un outils pour ça : git-octopus.
Alors si vous voyez débarquer dans vos équipes un type qui vous vante les mérites du feature branching, et que c'est peanuts avec git et que Git flow c'est une tuerie, le même qui ne s'est jamais paluché un vrai merge des familles avec du refactoring sur le nom des packages et des classes, les changements sur les schémas de base de données, un conseil … Fuyez !!!
Bof. J'ai tendance à fuir celui qui me dis de fuir. Actuellement j'ai l'impression qu'on a une explosion des workflow et c'est une très bonne chose ! Les gens font ce qui marche pour eux. Ce n'est pas qu'une histoire de technique, il y a aussi de l'humain des gens qui préfèrent ou trouvent plus simple une façon plutôt qu'une autre. Je suis justement d'accord qu'il faut remettre en cause git-flow par exemple, parce que le meilleur workflow c'est celui qui convient à ton équipe. Il faut juste pas faire l'inverse et considérer que tout ce qui ne te correspond pas est nul et il faut (ça va avec) regarder ce qui se fait ailleurs pour ne pas retomber dans des pièges que d'autres ont rencontré.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Et ce n'est pas possible. C'est le fait donner des accès qui a rendu intéressant les applet java. Résussir à mettre tout le monde d'accord sans moyen de pression est impossible. Java a permis de rendre accessible du matériel sur le net sans que les fabricants du matériel et les navigateurs n'aient besoin de se mettre d'accord sur une API.
Ouai alors moi j'ai vu pas mal de jeux vidéo en appel java aussi. L'intérêt de l'accès au matériel est plutôt limité dans ces cas là.
Ça tombe bien, il n'y a plus d'intérêt aux applets java.
Bien, dis moi comment tu utilise une smartcard pour signer un document sur un site web sans applet java.
Sans pourrir la sécurité de ton client en lui faisant installer c'te daube ? Je ne sais pas. Sinon tu peux le faire avec un activeX si je ne m'abuse.
Le principe de base c'est quand même que les smartcard c'est horriblement mal foutue. Pour avoir fais de l'authentification web avec ça, c'est une gageure bien pourrie d'avoir à charger dans son navigateur une bibliothèque native pour charger le driver du lecteur de carte pour espérer que ça fonctionne…
Si tu veux faire tout et n'importe quoi tu peux aussi simplement créer un logiciel :) Java webstart t'aidera à déployer ça plus facilement. Sans limitation et avec bien moins de failles de sécurité.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Non c'est bien ce que je dis c'est le fait d'être exhaustif de base qui le rend si compliqué à sécuriser.
Si tu limite autant le Java que le JS, il n'y a plus d'intérêt au Java (ou du moins, beaucoup moins).
Ça tombe bien, il n'y a plus d'intérêt aux applets java. Quand on en utilisait, c'est parce que JS était lent et limité. Aujourd'hui, il a beaucoup gagné en vitesse et possibilité.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Oui globalement l'ordinateur (fix ou portable) en mode desktop, est en très net recul depuis quelques années. L'arrêt d'XP avait permis une relance, mais il me semble que la tendance est forte.
Les smartphones, pour beaucoup d'usages (allez, exemples : gravure, travail un minimum sérieux, développement, écriture, une expérience Web confortable, édition audio/vidéo, etc…) , sont inadéquats.
La gravure c'est has been, les supports USB sont largement moins chères et plus pratiques, le réseau aussi. Je n'ai pas trouvé les chiffres de ventes de CD/DVD vierge ou de graveur. Mais les prix des blueray vierge et de leur graveur montrent à mon avis qu'il n'y a pas de grosse demande des clients (le volumes de données utilisé augmente et les supports resteraient à taille fixe ? J'ai du mal à le croire)
travail un minimum sérieux : ça c'est peut être un peu subjectif, non ? Ça me fait penser à ceux qui pensent que pour faire un travail un « minimum sérieux », il faut avoir une chemise et une cravate. Prendre des notes, communiqué, ce fait très bien sur tablette par exemple.
développement : effectivement et comme toute la population fait du développement c'est très pertinent comme argument
une expérience Web confortable : personnellement pour naviguer hors boulot, je suis la majorité du temps sur android (téléphone ou tablette), le confort de ne pas avoir à se poser avec un PC portable ou s'installer à un bureau est plus important pour moi que le confort que tu perd. Grosso modo ton site est pas pratique (sans être vraiment responsive) sur tablette, je passe mon chemin.
[…] il est possible d'aller plus loin en modélisant tout son logiciel en UML et en générant une partie du code source.
Qu'entends-tu par « partie » ? Faut-il modifié le code généré ? Si oui lorsque l'on fait une évolution, il faut alors regénérer puis re-modifier ces même sources ?
Mais les diagrammes de séquence ne servent pas qu'à ça, hein ? Tu peut vouloir présenter un cas précis de communication entre un serveur sur le quel tu n'a pas la main et ton client, tu peux présenter des choses à un assez haut niveau, tu peux voir ça à partir d'une trace généré (par exemple une capture tcpdump),…
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Sinon à changer de langage pour ça, j'imaginerais plus go qui a pas mal plus aux développeurs python et qui a 2 grands avantages : il se crosscompile très facilement et il génère de base des binaires statiquement liés. C'est parfait pour les déploiements simplifiés (→ sans aucune dépendance).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Ben non. ton svn commit ne marche pas si ton origin a avancé, il faut un rebase avant. Et bien sur tu choisi tes fichiers
ton svcheckout, tu ne veut pas de git pull, mais un rebase, pour éviter des merges inutiles, si tu as fait des commit avant.
Comme je disais ils sont écris à l'arrache :)
En tout cas, je ne connaissais pas les alias.
Content d'avoir était utile alors, c'est assez pratique d'autant qu'ils sont pris en compte par l'autocomplétion.
J'en abuse pas, mais j'apprécie énormément de pouvoir avoir :
Tu pourra trouver pleins d'exemple de log amélioré sur internet (le miens n'est pas de moi d'ailleurs) et pouvoir avoir un commit par ligne en couleur etc c'est le pied :)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Le truc, c'est qu'il faut 4 commandes au lieu d'une.
Euh… Elles ont toutes un sens propre. Je veux dire, personnellement, je n'ai pas de séquence de 2 ou 3 commandes que je lance systématiquement ensemble. J'aurais tendance à dire que travailler vraiment comme SVN (avec des commits réseau par exemple) perds beaucoup de l'intérêt de l'outil.
J'imagine qu'il faudra attendre un outil qui masque cette complexité en forçant une manière de faire.
Ou simplement te créer les alias git qui vont bien par exemple (écris à l'arrache
Tu passes ton temps à savoir si faut faire commit, stash, rebase, push. Tout ça pour faire l'équivalent d'un commit SVN.
J'ai pas l'impression de galérer avec ça.
rebase et non merge tout le temps
Hum… En principe je fais un rebase de ma branche vers le master (donc ma branche est à jour du master), puis un rebase -i pour réécrire l'historique comme je veux, puis depuis le master je merge ma branche. Sa sérialise l'historique oui, mais globalement je me fous de savoir qu'il y avait une branche et mon serveur est un SVN (sic) donc je ne suis même pas sûr de ce que ça donnerait comme historique autrement.
D'ailleurs même avec du git sur serveur, pour ne pas se servir de merge, ça veut dire que tu garde toutes tes branches sur le serveur (git refuse de supprimer les branches non mergées de base) ? Ou il y a quelque chose pour « fermer une branche », juste histoire de ne pas avoir plusieurs millier d'entrée quand tu fais un fetch -a par exemple.
[…] mais l'historique n'est pas historisé, donc tu ne peux pas facilement revenir en arrière parfois.
Quand je maîtrisais encore moins qu'aujourd'hui, j'utilisais format-patch pour garder une ancienne version de l'historique en locale. Mais tu peux le faire avec des branches locales de backup (ou archiver ton dépôt avec un tar -). Je trouve le fait de travailler en local très rassurant au contraire.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Note : de base même sans lire le reste l'illustration me gêne beaucoup (et ce n'est pas que pour se séminaire). Amalgamer le « big data » à la surveillance est assez risible. Le big data/machine learning/système d'information décisionnel c'est vieux, très vieux et ça a énormément d'applications qui ne portent en aucun cas atteinte à la vie privé des gens.
Aujourd’hui les nouvelles applications numériques, dans le domaine des transports, de l’hôtellerie, de l’édition, rebattent brutalement et rapidement les cartes. Même si la remise en question des rentes de position et de corporations d’un autre âge est souvent justifiable, la disparition de métiers et de branches professionnelles soulève des questions de toute autre ampleur.
La disparition de métier n'est pas plus lié au big data qu'au numérique, qu'à l'utilisation de l'électricité, la création de la machine à vapeur, le développement du train ou autre. Au fur et à mesure que nous évoluons technologiquement nos métiers changent. Nous avons quasiment plus de chasseurs, est-ce qu'il faut vilipender les éleveurs ? Les remettre en question et les pointer du doigt ?
Cette mutation économique en cours n’est pas seulement mue par la recherche du profit. Elle porte aussi à dessein l’idéologie d’une humanité augmentée dans une société diminuée.
Rien que ça… Globalement affirmer que ce qui est faisable par une machine devrait l'être histoire que l'humain se concentre sur le social, ça me paraît pas mal, non ? C'est un peu ce qu'on a toujours fait. La question n'est jamais d'informatiser pour informatiser, mais que l'informatique trouve sa place (si elle en a une) pour simplifier, accélérer, améliorer le travail. Par améliorer je en dis pas que la machine fait mieux que l'Homme, mais qu'elle permet à se dernier de mieux travailler (en lui présentant des informations plus pertinente ou en réduisant sa charge de travail).
Je ne m'y intéresse pas beaucoup, mais je peux te citer des cas d'informatisation/big data qui n'ont pas fonctionné. Ce n'est pas une marche inéluctable, c'est des expérimentations pour trouver la bonne place.
Il s’agit dès lors de porter un regard critique face aux intérêts propres liés à la défense et à l’évolution des métiers.
Tout à fait et partir avec comme postula :
« on détruit nos métiers »
« le big data c'est comme big brother »
Me semble être des généralisations largement excessives qui ne permettent pas d'aborder ces questions sereinement.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Rrrr Zzzz
Posté par barmic . En réponse au journal Git Rev News: la newsletter de Git, et sondage pour utilisateurs de Git. Évalué à 4.
Ce serait super intéressant ! :)
En fait pour ce genre d'alias tu peut simplement faire :
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: FUD ?
Posté par barmic . En réponse à la dépêche Séminaire de réarmement intellectuel et technique sur le "Big Data". Évalué à 8.
Non. Le big data est un ensemble de techniques permettant de manipuler une quantité arbitraire de données.
Tu cherche à l'associé avec l'un des usages qui en est fait, mais c'est une généralisation très malheureuse.
Le big data n'a rien avoir avec la collecte de données personnelles. Quand un super marché prends tous ses tickets de caisse les fou dans une base et fait du machine learning, ça n'est en rien de la collecte de données personnelles. Pourtant si c'est Carrefour ou Wallmart qui le fait ils vont avoir des problématique adressés par le big data. Si tu es une banque et que tu dois pour lutter contre le blanchiement d'argent pouvoir fournir une traçabilité complète de toutes les comptes, tu va devoir faire du big data. Si tu as un tas de capteurs qui t'envoient des données de manière régulière ou continue, tu fera du big data.
Le big data ne sont que des techniques pour scaler sur ton volume de données, rien de plus.
C'est un outil à la collecte des données au même titre qu'internet.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Ce manuel est publié sous licence GPLv3
Posté par barmic . En réponse à la dépêche Les cahiers du débutant Debian, un guide non conventionnel ouvert en écriture. Évalué à 4.
Je ne suis pas d'accord avec Debian :)
Autant clairement la GFDL est une erreur dans la nature, autant je ne trouve pas qu'il soit judicieux d'utiliser une licence logiciel pour une documentation. Il existe des licences plus spécifiques qui sont plus compréhensible pour les potentiels contributeurs à une documentation. Bien sûr je pense aux CC qui font office de standard de fait pour tout ce qui n'est pas à proprement dis exécutable (j'ai assez peur de la transposition qui peut être fait devant une coure de justice de code source ou d'exécution pour de la documentation). Après évidement une licence type RABL n'est pas plus logiciel qu'autre chose ;)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Multiprotocole
Posté par barmic . En réponse au journal jus - Just Upload Stuff. Évalué à 5.
Il faut que je me penche là dessus, parce que je ne suis pas non plus satisfait de ma solution…
J'aimerais personnellement avoir de l'envoie scp, https, bitorrent ou synthings et de la récupération bitorrent ou https avec une interface d'admin pour gérer tout ça.
bt est super pratique pour la manipulation de très gros fichiers (genre 5Gio et plus) pour la performance, mais aussi pour la gestion de la bande passante et pour la reprise du transfert.
Ce serait génial, mais ce ne sera de toute manière pas aussi pratique à mettre en place.
Merci du partage ! :)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: La fin de Mozilla ?
Posté par barmic . En réponse au journal Firefox hello sera bronsonisé. Évalué à 4.
Oui et c'est normal car ce sont des techno et pas des fonctionnalités. Passer des années à mûrir des fonctionnalités ce serait extrêmement préjudiciable. Ça la même déjà était à l'époque de Firefox 4.
Ou alors comme les rageux ne viennent pas faire de retour sur les canals nigthly ou beta et ne sont pas non plus inscrit à la liste UX de Firefox. Ils n'ont aucun autre moyen que leur dont de voyance pour savoir ce qui va te plaire ou non. Il y a un moment où il faut comprendre que :
Utiliser un firefox plus à jour que stable pour faire remonter ce qui te plaît ou pas. Ça n'est pas un investissement important. S'inscrire à la liste UX non plus.
Se plaindre que les décisions ne sont pas prises de manière communautaire et ne rien faire pour tenter de s'inscrire dans la communauté c'est ridicule. C'est du logiciel libre, ça implique certaines choses au cas où certains n'auraient pas compris (voir la méritocratie dans le LL pour ceux qui ne savent pas de quoi il s'agit).
On parle bien de chose que même des membres de linuxfr ne connaissent pas ? (https://linuxfr.org/users/devnewton/journaux/firefox-hello-sera-bronsonise#comment-1673892)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: La fin de Mozilla ?
Posté par barmic . En réponse au journal Firefox hello sera bronsonisé. Évalué à 8.
Non. c'est l'incapacité à innover qui fait ça. Quand une organisation n'a plus le droit à l'erreur, qu'elle ne peut plus essayer quelque chose sans devoir le maintenir des années, alors c'est que c'est très très mal parti. Personnellement je suis très content de voir Mozilla essayer des choses certaines ratées (Hello ou le truc d'authentification par exemple) d'autres plutôt réussi (Servo, Rust). C'est le fait de se perdre à maintenir des projets pour la beauté du geste qui risquerait de tuer Mozilla.
Après on peut leur reprocher leur choix, mais que ce soit Mozilla, Google ou je ne sais qui. C'est plutôt bon signe pour eux de voir qu'ils sont capable d'arrêter quelque chose qui ne rempli pas leurs objectifs (oui je sais SQL est resté en gestation pendant 8 ans avant de sortir de chez IBM, un peu comme Rust en fait…).
S'il y a une chose qui me paraît bonne de ce qu'on m'a dit de la culture américaine et qui la sépare de nous, c'est cette capacité à voir de manière positive le fait d'avoir essayer même lors d'échec. Ça permet de ne pas rester tétanisé par la peur de l'échec.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Chiffres de ventes publics
Posté par barmic . En réponse à la dépêche Angular 2 est en version finale, Ninja Squad vous met le pied à l’étrier. Évalué à 10.
Hum, hum… Intéressant…
Parlez-moi de votre père…
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Rrrr Zzzz
Posté par barmic . En réponse au journal Git Rev News: la newsletter de Git, et sondage pour utilisateurs de Git. Évalué à 4.
AMHA il y en a plus. Il est tout à fait possible de créer un gitflow-like pour ton workflow. gitflow a précisément était créé pour ça : simplifier une méthode de développement.
Je pense que c'est une bonne chose d'avoir un outil agnostique puis d'avoir des plugins/surcouche « opinionated » comme disent les anglosaxons.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: PlantUML
Posté par barmic . En réponse à la dépêche Écrire des diagrammes de séquences. Évalué à 4.
Comme ça je dirais que c'est pratique quand tu veut décrire un scénario dans un système P2P avec des évènements qui arrivent sur 2 nœuds simultanément.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Workflow git
Posté par barmic . En réponse au journal Git Rev News: la newsletter de Git, et sondage pour utilisateurs de Git. Évalué à 3.
C'est peut être mal perçu. Je suis au contraire content que ça existe. Je suis friand de retours d’expérience, même si IRL je n'ai que rarement mon mot à dire là dessus. C'est au moins pour l'esprit ;)
Dans mon monde on en est pas là (sic), on à pas d'IC sur les branches et on a pas suffisamment de tests d'intégration…
Merci de ton retour :)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: firefox
Posté par barmic . En réponse au journal Java dans le navigateur : ce n'est pas fini, ça sera pire !. Évalué à 8.
Bof globalement il vit là où il en a envie. Ça marche avec une chaîne d'outils signée. L'UEFI accepte de lancer uniquement un bootloader signé qui n'accepte de lancer qu'un noyau signé qui n'accepte de lancer que des binaires signés. Et tout ça se base sur l'idée que tu passe par un provider de logiciel qui va signer tout tes logiciels pour toi. C'est ce que fait Apple sur iPhone si j'ai bien compris. Je ne connais pas de machines de bureau quelque soit l'OS qui fasse quelque chose d'aussi complet. Donc ton malaware, s'il ne peux pas remplacer le bootloader, il remplacera le noyau ou se chargera dedans, au pire il remplacera ton système d'init. En terme de puissance néfaste c'est la même chose, il n'y a qu'en terme de facilité à le détruire que les choses sont un peu différentes.
Mais du coup les clients, ils refusent linux parce qu'il n'y a pas secure boot ? Ils sont aussi du genre à refuser parce qu'ils trouvent que l'implémentation de
malloc(3)dans la libc n'est pas à leur goût ou bien ?Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Rien de neuf
Posté par barmic . En réponse au journal Java dans le navigateur : ce n'est pas fini, ça sera pire !. Évalué à 4.
T'es pas le premier à qui j'ai envie de faire la remarque. Le P2P c'est bien pour les débit, pas pour la latence. Ce n'est pas le truc optimal qui va marcher pour tout. Du streaming, des petits fichiers etc ça match pas très bien (ça vient du protocole et de ton ADSL).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: oui mais non
Posté par barmic . En réponse au journal Firefox hello sera bronsonisé. Évalué à 3.
Il ne fonctionne pas sur mon téléphone que ce soit avec Firefox ou Chrome.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Workflow git
Posté par barmic . En réponse au journal Git Rev News: la newsletter de Git, et sondage pour utilisateurs de Git. Évalué à 3.
Justement quand je lis son poste « SemanticConflict » que tu as cité et que je lis sa première phrase :
C'est pour moi exactement l'inverse, si quelque chose est difficile, il faut le faire plus souvent. Si on ne fait pas quelque chose parce qu'elle est difficile, elle restera forcément difficile. Alors que si tu te casse les dents dessus 2, 3, 20 ou 30 fois. Tu va mécaniquement t'améliorer et trouver des solutions pour résoudre tes problèmes.
Pour le feature branch, il n'y a pas de différence notable entre un mec qui développe dans son workspace sans soumettre son code et sans mettre à jour sa base de code (ce que je vois tous les jours) et le feature branche. C'est juste que ce dernier est nommé et est plus correctement outillé. Encore une fois plus ton équipe est petite et mieux ça se passe (les merges peuvent être fait à 2). Personnellement je n'ai jamais trouvé que les merges soient véritablement difficile quand tu n'a pas des gens qui passent des semaines sans faire de merge/rebase.
Le Branching by Abstraction je ne crois pas que ce soit autre chose qu'une vue de l'esprit. Je n'ai jamais vu des gens en faire pour de vrai. Je pense que c'est trop complexe pour véritablement être mis en place.
C'est un peu de l'argumentation d'autorité ça ;) M. Fowler est intéressant, mais c'est pas mal d'aller voir ce qui se fait ailleurs (surtout qu'il y a pleins de gens qui parlent de leur expérience sur ce genre de sujets).
C'est surtout pas toujours faisable d'un point de vu non technique (si le déploiement consiste à aller en centrale nucléaire installer ta nouvelle version de logiciel qui met un bout de matos en indispo, pour te cité un cas que je connais et qui est extrême).
Mais je ne suis pas d'accord sur le fait que ta stratégie de branching va jouer sur ta stratégie de release/déploiement. Encore une fois les furets ne suivent pas du tout ton idée et ils font autant de déploiement qu'ils le souhaitent (de tête plusieurs par semaine, un déploiement se fait en ~ 2h). D'ailleurs je ne me souviens pas d'avoir entendu Sacha Labourey (si tu veux que je cite une autre référence) parler de stratégie de branchement pour parler de continus deployment.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Workflow git
Posté par barmic . En réponse au journal Git Rev News: la newsletter de Git, et sondage pour utilisateurs de Git. Évalué à 4.
Non ou plutôt tes arguments ne suffisent pas :)
Et tu arrive à le savoir a priori ?
D’expérience, là où j'ai travaillé, personne n'était assez mature pour faire ça sans complètement exploser la complexité du code et sans se perdre dans toutes les fonctionnalités.
Ouai bof, ça n'est pas vraiment un problème. Faut rebaser fréquemment. Sur des petites équipes ça ne pose aucun problème. Ton intégration continue elle doit surtout être toujours verte, tu dois pouvoir livrer à tout moment, à la fréquence qui te semble opportune et pas à la fréquence que tu es capable de faire. Donc non tu ne peux pas accepter qu'un gars commit une erreur ou un truc qui a un effet de bord indésiré. Si tu veux, tu peux contraindre ton IC à faire un rebase fréquent (si la branche à lancer n'est pas assez à jour la passer en erreur).
Ça n'est pas une vérité générale. J'ai vu une conférence des furets. Ils n'ont pas de master et font systématiquement du big bang merge comme tu dis. Ils ont créé un outils pour ça : git-octopus.
Bof. J'ai tendance à fuir celui qui me dis de fuir. Actuellement j'ai l'impression qu'on a une explosion des workflow et c'est une très bonne chose ! Les gens font ce qui marche pour eux. Ce n'est pas qu'une histoire de technique, il y a aussi de l'humain des gens qui préfèrent ou trouvent plus simple une façon plutôt qu'une autre. Je suis justement d'accord qu'il faut remettre en cause git-flow par exemple, parce que le meilleur workflow c'est celui qui convient à ton équipe. Il faut juste pas faire l'inverse et considérer que tout ce qui ne te correspond pas est nul et il faut (ça va avec) regarder ce qui se fait ailleurs pour ne pas retomber dans des pièges que d'autres ont rencontré.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Rien de neuf
Posté par barmic . En réponse au journal Java dans le navigateur : ce n'est pas fini, ça sera pire !. Évalué à 3.
Ouai alors moi j'ai vu pas mal de jeux vidéo en appel java aussi. L'intérêt de l'accès au matériel est plutôt limité dans ces cas là.
Sans pourrir la sécurité de ton client en lui faisant installer c'te daube ? Je ne sais pas. Sinon tu peux le faire avec un activeX si je ne m'abuse.
Le principe de base c'est quand même que les smartcard c'est horriblement mal foutue. Pour avoir fais de l'authentification web avec ça, c'est une gageure bien pourrie d'avoir à charger dans son navigateur une bibliothèque native pour charger le driver du lecteur de carte pour espérer que ça fonctionne…
Si tu veux faire tout et n'importe quoi tu peux aussi simplement créer un logiciel :) Java webstart t'aidera à déployer ça plus facilement. Sans limitation et avec bien moins de failles de sécurité.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Rien de neuf
Posté par barmic . En réponse au journal Java dans le navigateur : ce n'est pas fini, ça sera pire !. Évalué à 3.
Non c'est bien ce que je dis c'est le fait d'être exhaustif de base qui le rend si compliqué à sécuriser.
Ça tombe bien, il n'y a plus d'intérêt aux applets java. Quand on en utilisait, c'est parce que JS était lent et limité. Aujourd'hui, il a beaucoup gagné en vitesse et possibilité.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: firefox
Posté par barmic . En réponse au journal Java dans le navigateur : ce n'est pas fini, ça sera pire !. Évalué à 2.
On dit que rire c'est bon pour le corps, mais je crois que ce n'est que quand c'est sincère. Quand c'est forcé comme vous le faite, c'est juste nul.
Donc :
Premier lien que je trouve : http://www.zdnet.fr/actualites/chiffres-cles-le-marche-des-pc-39380521.htm
Oui globalement l'ordinateur (fix ou portable) en mode desktop, est en très net recul depuis quelques années. L'arrêt d'XP avait permis une relance, mais il me semble que la tendance est forte.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Déjà dis
Posté par barmic . En réponse au journal Firefox hello sera bronsonisé. Évalué à 10.
On en avait déjà parlé à la dernière dépêche : https://linuxfr.org/news/firefox-48-api-webextensions-electrolysis-et-securite#disparition-de-hello
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Aller encore plus loin
Posté par barmic . En réponse à la dépêche Écrire des diagrammes de séquences. Évalué à 3.
Qu'entends-tu par « partie » ? Faut-il modifié le code généré ? Si oui lorsque l'on fait une évolution, il faut alors regénérer puis re-modifier ces même sources ?
Mais les diagrammes de séquence ne servent pas qu'à ça, hein ? Tu peut vouloir présenter un cas précis de communication entre un serveur sur le quel tu n'a pas la main et ton client, tu peux présenter des choses à un assez haut niveau, tu peux voir ça à partir d'une trace généré (par exemple une capture
tcpdump),…Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Reste en python
Posté par barmic . En réponse au journal Écrire des diagrammes de séquences. Évalué à 3.
Sinon à changer de langage pour ça, j'imaginerais plus go qui a pas mal plus aux développeurs python et qui a 2 grands avantages : il se crosscompile très facilement et il génère de base des binaires statiquement liés. C'est parfait pour les déploiements simplifiés (→ sans aucune dépendance).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Rrrr Zzzz
Posté par barmic . En réponse au journal Git Rev News: la newsletter de Git, et sondage pour utilisateurs de Git. Évalué à 4.
Comme je disais ils sont écris à l'arrache :)
Content d'avoir était utile alors, c'est assez pratique d'autant qu'ils sont pris en compte par l'autocomplétion.
J'en abuse pas, mais j'apprécie énormément de pouvoir avoir :
Tu pourra trouver pleins d'exemple de log amélioré sur internet (le miens n'est pas de moi d'ailleurs) et pouvoir avoir un commit par ligne en couleur etc c'est le pied :)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Rrrr Zzzz
Posté par barmic . En réponse au journal Git Rev News: la newsletter de Git, et sondage pour utilisateurs de Git. Évalué à 10.
Euh… Elles ont toutes un sens propre. Je veux dire, personnellement, je n'ai pas de séquence de 2 ou 3 commandes que je lance systématiquement ensemble. J'aurais tendance à dire que travailler vraiment comme SVN (avec des commits réseau par exemple) perds beaucoup de l'intérêt de l'outil.
Ou simplement te créer les alias git qui vont bien par exemple (écris à l'arrache
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Rrrr Zzzz
Posté par barmic . En réponse au journal Git Rev News: la newsletter de Git, et sondage pour utilisateurs de Git. Évalué à 5.
Je suis très loin d'être un spécialiste…
J'ai pas l'impression de galérer avec ça.
Hum… En principe je fais un rebase de ma branche vers le master (donc ma branche est à jour du master), puis un
rebase -ipour réécrire l'historique comme je veux, puis depuis le master je merge ma branche. Sa sérialise l'historique oui, mais globalement je me fous de savoir qu'il y avait une branche et mon serveur est un SVN (sic) donc je ne suis même pas sûr de ce que ça donnerait comme historique autrement.D'ailleurs même avec du git sur serveur, pour ne pas se servir de merge, ça veut dire que tu garde toutes tes branches sur le serveur (git refuse de supprimer les branches non mergées de base) ? Ou il y a quelque chose pour « fermer une branche », juste histoire de ne pas avoir plusieurs millier d'entrée quand tu fais un
fetch -apar exemple.Quand je maîtrisais encore moins qu'aujourd'hui, j'utilisais
format-patchpour garder une ancienne version de l'historique en locale. Mais tu peux le faire avec des branches locales de backup (ou archiver ton dépôt avec un tar -). Je trouve le fait de travailler en local très rassurant au contraire.Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# FUD ?
Posté par barmic . En réponse à la dépêche Séminaire de réarmement intellectuel et technique sur le "Big Data". Évalué à 10.
Note : de base même sans lire le reste l'illustration me gêne beaucoup (et ce n'est pas que pour se séminaire). Amalgamer le « big data » à la surveillance est assez risible. Le big data/machine learning/système d'information décisionnel c'est vieux, très vieux et ça a énormément d'applications qui ne portent en aucun cas atteinte à la vie privé des gens.
La disparition de métier n'est pas plus lié au big data qu'au numérique, qu'à l'utilisation de l'électricité, la création de la machine à vapeur, le développement du train ou autre. Au fur et à mesure que nous évoluons technologiquement nos métiers changent. Nous avons quasiment plus de chasseurs, est-ce qu'il faut vilipender les éleveurs ? Les remettre en question et les pointer du doigt ?
Rien que ça… Globalement affirmer que ce qui est faisable par une machine devrait l'être histoire que l'humain se concentre sur le social, ça me paraît pas mal, non ? C'est un peu ce qu'on a toujours fait. La question n'est jamais d'informatiser pour informatiser, mais que l'informatique trouve sa place (si elle en a une) pour simplifier, accélérer, améliorer le travail. Par améliorer je en dis pas que la machine fait mieux que l'Homme, mais qu'elle permet à se dernier de mieux travailler (en lui présentant des informations plus pertinente ou en réduisant sa charge de travail).
Je ne m'y intéresse pas beaucoup, mais je peux te citer des cas d'informatisation/big data qui n'ont pas fonctionné. Ce n'est pas une marche inéluctable, c'est des expérimentations pour trouver la bonne place.
Tout à fait et partir avec comme postula :
Me semble être des généralisations largement excessives qui ne permettent pas d'aborder ces questions sereinement.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)