Alex G. a écrit 649 commentaires

Oui il ne faut pas oublier qu'en face des décideurs il y a le marketing des vendeurs de machines. Donc les décisions ne sont pas forcément rationnelles.

Wow merci !

Erf moi j'avais fondé ma lemmatisation sur cette information de hunspell (j'utilise Polyglot qui fournit l'étiquetage sémantique mais pas la lemmatisation) je pensais même à contribuer ça a polyglot (quand bien testé).
Du coup ce serait mieux que je cherche la partie de code python qui fait ça dans Grammalecte ?

Je vois que ton code n'est pas découpé en packages et j'ai l'impression que même la version javascript et python sont tous ensemble. Tu comptes un peu découper tout ça a un moment donné ? (pour favoriser la réutilisation).

Salut Renault, bravo pour ta connaissance de la langue française. Sans vouloir provoquer ton courroux, peut être est-ce le biais du débat écrit, mais tu apparais ici comme un Grammaire Warrior (mais le débat est de qualité). En laissant les armes de côtés, ça me semblerait utile que tu aides Olivier dans son projet, en acceptant quelques irrégularités de sa part ;-) (c’est un juste encouragement).

Hello, l'importance du sujet, la qualité de ta rédaction font que ce journal devrait être une dépêche à mes yeux.

Pourquoi as tu choisis le format journal ?

Je suis d'accord que des messages de commit clair c'est une forme de politesse pour le futur lecteur (qui sera un étranger ou souvent sois-même dans le futur !). C'est comme le sujet pour un mail.

En fait ceux qui font du Python vont souvent te dire que le temps qui est le plus cher c'est celui du programmeur (pas celui de la machine). Or en Python tu es généralement plus productif qu'en C (le contraire est quand même très difficile à soutenir).

Mais bien sur c'est toujours un compromis, et si ton programme est déployé sur des milliers de machines et en permanence ça vaut sûrement le coup de l'optimiser (ou au moins c'est défendable).

Excellent commentaire merci.

Pour moi le premier problème n'est pas tant le PIB mais le dogme qu'il semble représenter. Notamment : pas d'emplois sans croissance de PIB… (je sais pas combien de fois je l'entends de manière dogmatique dans les média). Pourtant l'augmentation du temps de travail peut aussi être affecté par la baisse du temps de travail ou bien une meilleure répartition des salaires…

Le deuxième problème est que le PIB mesure l'activité économique mais absolument pas la qualité de vie, si les forces économiques sont mis au service de la personne. Par exemple la fabrication d'armes chimique augmente le PIB. C'est difficile donc d'en faire un objectif politique absolu comme on le voit malheureusement trop (et encore dans cette élection présidentielle c'était beaucoup moins en avant).

Peut être devrait tu l'approprier un workflow qui utilise une branche. Avec un rebase et écrasement des commit lors d'un merge des branches.

Mais bon avoir des commits propres c'est pas un objectif en sois, ça peut juste être un choix de méthode de travail pour une communauté donnée.

Merci beaucoup pour le lien. En tout cas ça montre qu'il y a aussi des méthodes pour cacher que l'on a rooté son téléphone (il parle de rootcloakers).

Je trouve assez fallacieuse, sa défense du pourquoi il faudrait empêcher l'installation sur un téléphone rooté. Comme d'habitude on suppose que les fabricants/intégrateurs de téléphones sont forcément compétents, honnêtes et bienveillants et le possesseur du téléphone, lui, à priori idiot.

Hello, au cas où il y aurait un spécialiste dans l'assistance, par quel moyen l'application sait-elle que l'appareil est rooté ?

Est-ce un mécanisme de clé qui signe l'OS ? Qui a ces clés ? Les constructeurs je suppose vu qu'ils ont eux même packagé le système (?)

N'y a-t-il pas moyen de détourner cet indicateur même ?

Ah et juste pour donner une idée:

In [12]: len(str(2**500000))
Out[12]: 150515

ce sont des nombres qui en décimal font 150000 chiffres.

En fait Python ne va pas déléguer l'opération directement au processeur comme d'autre langage, car il fait du "boxing", c'est à dire il ne permet pas à un nombre de déborder, mais gère des nombres aléatoirement grand.

J'ai pu utiliser ça il y a pas longtemps pour comparer des vecteurs de grandes tailles, et approximer un log likehood par un xor (ça marchait car je comparais deux vecteurs pour des valeurs oui/non, donc binaire). En gros je devais compter les faux positifs et faux négatifs (donc là où j'avais 1 quand j'aurais du avoir 0, et 0 quand j'aurais du avoir 1, ce que xor peut permettre de compter).
Je me suis aperçu que malgré la "mise en boite" (et donc pas mal de calculs en plus de la part de python), le xor restait assez rapide même sur de très grand nombres (de 500 000 chiffres).

In [5]: import random
In [7]: x = int("".join(random.choice(["0", "1"]) for i in range(500000)), 2)
In [8]: y = int("".join(random.choice(["0", "1"]) for i in range(500000)), 2)
In [9]: %timeit x ^ y
The slowest run took 10.90 times longer than the fastest. This could mean that an intermediate result is being cached.
100000 loops, best of 3: 8.94 µs per loop

Je pense que le premier essais est plus long à cause des chargement de la mémoire (pour les deux autres itérations, le cache du processeur joue).

C'est tout de même intéressant de montrer, quand ça arrive, une des limites du propriétaire, que tu n'as pas (au moins en théorie) dans le libre.

J'ai testé le processus et clairement c'est pas vraiment anonyme, si ce n'est qu'il faut leur faire confiance dans le traitement des données.
Par contre Facebook ne saura rien du vote (dans FB Messenger tu reçoit un lien qui t'envoie sur la plateforme de vote).

J'imagine que le problème pour eux et d'être sur que un vote = une personne. Vu que le temps presse (je pense que l'idée est née sur le tard), je pense que c'est pour ça qu'ils ont choisis facebook: les CGU de Facebook sont censé te forcer a un seul compte (clairement c'est pas du tout une vrai garantie). Et peut-être aussi qu'ils avaient déjà une expérience du développement d'un chatbot (automate conversationnel?) Facebook, ce qui leur permettait d'aller vite (je dois dire que c'est vraiment facile et agréable à utiliser). La doc de cocorico parle d'alternatives possibles.

Donc ta critique est clairement méritée, mais je pense que l'urgence leur a fait prendre cette décision discutable. Espérons qu'ils mettent rapidement en ligne une alternatives.

Après Facebook c'est peut être un filtre pour que seul les neuneus votent ;-)

Je comprends très bien ton aversion pour les termes qui sont plus marketing que techniques (et clairement "fullstack" en est un). Perso je ne suis pas totalement contre ce genre de terme, mais je suis toujours à la recherche d'une définition qui soit relativement juste, sachant qu'un terme marketing est vite galvaudé (tout le monde voulant tout de suite s'en réclamer vu que c'est à la mode).

Dans ce cas, je pense quand même que tu confonds la dimension verticale et horizontale. Fullstack veut marquer le fait que tu peux faire une appli web (relativement standard) de A à Z, si tu as le choix des technos, pas que tu connais toutes les technos possibles sur toute la pile (là il faudrait parler de omni-stack peut être ? à supposer que ça puisse même se concevoir !).

Voilà c'est mes deux cents sur le terme, sans grande conviction !

Pour ma part j'ai 10 ans d'expérience en télétravail dans 4 entreprises différentes ! Ce que je dis ensuite n'en ai pas moins subjectif !

Ce n'est pas que je le recherchais mais c'était d'abord le seul moyen que j'avais trouvé de travailler avec des techno libres. Dernièrement c'est plus pour des motifs perso de localisation.

Clairement le télé-travail demande un peu d'effort de la part des collègues qui sont dans les locaux. En particulier d'être un peu rationnel sur la gestion de la communication. Dans un milieu très geek beaucoup de communication passe facilement en messagerie instantané ce qui est un avantage dans ce cas, mais le quasi refus de la visio/audio conférence peut lui être handicapant (lenteur de l'expression d'opinions ou de sujets flous à l'écrit). Un plus pour moi est aussi quand le supérieur hiérarchique ou un collègue "perd" régulièrement un peu de temps pour donner des nouvelles générales.

Perso j'ai toujours eu des moments très régulier de présence physique dans la boite et ça me semble important pour avoir une relation plus mûre avec les personnes, ce qui évite ensuite les énervements ou mauvaises interprétation de la communication écrite.

Coté présence au travail, la présence obligatoire sur messagerie instantané aide à être rationnel, également le travail en équipe avec des compétences partagées (l'autre peu juger de l'avancement normal de ton travail). Aider les autres est aussi un excellent moyen de se rendre présent et de se faire apprécier.

Je pense par contre que c'est extrêmement difficile d'être le supérieur hiérarchique d'une personne qui ne serait pas en télétravail en étant sois même en télétravail (très difficile d'avoir un feeling sur l'intégration de la personne à l'équipe).

Coté débit de connexion, perso, tant qu'une visio conférence passe, pour moi ça suffit. En gros même à 2-3 Mo/s il me semble que je bosse facilement. Par contre la qualité de connexion est importante (très difficile de bosser sans internet). (Je bosse surtout avec des web app et ssh).

Le VPN est vraiment pratique pour éviter de demander une adaptation spécifique de la sécurité de tous les outils internes (mais bien sûr, ça dépend des outils utilisés).

C'est tout à fait le problème en sécurité informatique, le "seul un spécialiste peut le faire" est vite détourné par le fait qu'il y a un spécialiste qui le fait une fois, publie, et tout le monde peut le faire ensuite via un petit outil / script…

Juste pour info, pour pallier à ça on peut éventuellement utiliser devilspie2 qui permet de programmer des actions automatiques sur des fenêtres.

Tu as un petit logiciel open source qui permet la traversée de NAT : pagekite

L'auteur te propose un hébergement sur abonnement, mais c'est opensource

Tu peux assez facilement le coupler à VNC. Par contre je n'ai pas testé.

PS: c'est équivalent à utiliser un VPN sur un serveur publique par contre.

Gcolor2, pour relever une couleur sans avoir à lancer Gimp.

Ah je connaissais pas. Perso, j'utilise agave pour ça.

Non. Une part variable doit être basée sur des conditions s'appuyant sur des critères précis : objectifs, CA généré, etc. Et l'employeur ne peut pas décider spontanément que tu n'as pas atteint les objectifs car c'est contractuel.

Attention toutefois que dans certains cas l'employé n'a pas vraiment la maîtrise de tous les paramètres qui lui permettrait de faire valoir son droit.

Par exemple, je dois réussir un projet dans les temps mais mon employeur lui même met des battons dans les roues ou change les spécifications sans arrêt.

Tu as raison. Ceci dit suivant la capacité / rapidité de compréhension du client, tu as parfois l'impression de "perdre" (surtout dans les cas ou tu es au forfait en fait…)

Mais ceci dit j'aime aussi la discussion avec les gens qui ont une "autre logique", ça amène aussi à se reposer parfois des questions plus fondamentales, alors qu'on était prisonnier d'un détail logique. Ça amène aussi des découvertes par sérendipité (une réponse illogique qui amène à se rendre compte que le besoin est un autre).

Ah oui j'oubliais de dire que tout cela est aussi inhérent à ce que je nomme "métier de la connaissance" (voir Knowledg worker. On n'appréhende qu'un système ou un concept qu'avec le temps, qu'avec sa manipulation. Parfois ceci change complètement notre vision par rapport à la vision initiale. C'est la même chose pour l'API et le découpage du code, c'est souvent à la fin de projet qu'on a une idée plus claire de comment il aurait fallu faire…
Et c'est bien le problème que tente d'adresser les méthodes agiles.

Tout d'abord merci pour ce journal, je trouve vraiment intéressant de prendre du recul comme ça. De plus le développement de projet au forfait n'est vraiment pas un métier facile.

Les API bien faite c'est vraiment le Graal, ce qui rende le produit évolutif et perso je pense qu'il faut au contraire pouvoir les casser pour arriver petit à petit à la bonne convergence. Seule règle que je trouve intéressante : les API de haut niveau devrait parler en langage métier (utiliser les mots / les concepts) c'est ce qui bougera le moins. Bien sur on a souvent besoin d'aller dans plus de détails technique (par exemple on a pas seulement des utilisateurs mais on doit se connecter à une BDD ou un LDAP…) doivent la encore refléter le mots de cet univers technique et si possible être dé-corrélées.

Concernant les tests, j'ai déjà essayé de faire des tests qui produisaient en sorti un scénario : je suis tel utilisateur, je fais ça puis ça, il se passe ça, etc… j'ai vu que malheureusement, comme j'ai dit dans un commentaire précédent, les clients n'ont souvent pas la volonté de vérifier tout ça ou pas la compétence d'en vérifier la cohérence. Le dialogue de personne à personne, l'écoute et l'intuition du besoin et du métier, la capacité de raisonnement et de créativité restent souvent les meilleurs facteurs de succès.

Le découpage en responsabilité et composants est également important et là encore très difficile à juger du premier coup. Par exemple je pourrais souvent, au début, mettre utilisateurs, groupes et permissions ensemble, mais si ça se complexifié ça devient un poids. De plus il faut éviter les dépendances croisées (A dépend de B qui dépend de A) qui sont une plaie pour les évolutions (il faut un A' qui dépend de A et B et éventuellement un B' qui dépend aussi de A et B) mais c'est très difficile de prendre la décision de refactorer au bon moment. Car sinon on va être dans l'over-engineering. Mais en pratique on se rend souvent compte trop tard, qu'à force d'entorses, on aurait dû séparer en plusieurs responsabilités. C'est de la dette technique et peu de client acceptent de payer pour ça (ou il faut vraiment une relation de confiance).

Tout cela sans compter que dans mon expérience sur une équipe de dév il y aura souvent 60% des gens qui n'auront pas une grande attention à ces discours, les trouverons obscurs ou superflus, ou simplement auront une petit flemme de bien faire et ne suivront donc que partiellement ces consignes…

Bref, je ne pense pas qu'il y ai de silver bullet. Par contre effectivement avoir une personne qui, dans l'équipe, tient l'œil sur ces points, mener des réflexions ensemble là dessus, est toujours intéressant et peut porter à un mieux.