groumly a écrit 3288 commentaires

Pour faire du télé travail depuis plus de 4 ans, la productivité est pas aussi bonne, et c'est usant pour le mental.
Je perd un temps fou en communication parce que hipchat/slack/email ne remplace clairement pas un contact physique, et c'est beaucoup plus dur de tisser des relations de travail efficaces (pas de machine a cafe, pas de pot après le boulot).
Les "all hands" meetings (point mensuel/trimestriel sur la boite, les projets, le business, etc.) deviennent aussi plus compliqué d'un coup.
Les Hangout, ca marche tres bien 80% du temps, mais les 20% qui restent sont difficiles.
Si t'es un manager et que t'as reports direct, Ben faut les voir en personne. Une discussion difficile avec un mec qui fait du mauvais boulot est beaucoup plus difficile à avoir à distance. Et c'est encore plus dur de tisser une bonne relation manager/employé si tu vois pas tes gars au quotidien.

Sur mon mental, j'ai fait télé travail pur pendant qq mois, ne pas avoir de contact humain dans la journée, ca pèse. Et si t'as des gosses à la maison, ca devient dur de bosser.
Je me tape aussi un vol LA/SF toutes les semaines, et l'aéroport à 6:30 du mat', Ben je m'en passerais bien tu vois (ok, tout le monde ferait pas ca avec du télétravail).

Bosser de la maison en caleçon, c'est marrant les 2 premières semaines, après ca pèse, et t'es obligé de prendre un rythme et te forcer à prendre des habitudes et une routine.

Je dit pas que c'est impossible (ca fait 4 ans que je le fait), mais c'est clairement pas aussi simple que certains voudraient le faire croire.
Ce qui est idéal par contre, un bureau dans la même ville que toi, avec la possibilité de bosser de la maison un peu quand tu veux. En gros, tu viens 50-80% du temps, tu bosses de la maison le reste du temps (quand les transports sont en grève, quand t'as un paquet qui doit être livré, quand tu doit partir du taff, ce genre de choses). Ca, ca marche tres bien dans mon experience.

Ce que tu dis (et les autres aussi, seul argument objectif pour cette acquisition) est que Mozilla fait à la Google, soit.

Comment ca, à la google? Toute l'industrie fait ca, racheter des startup pour les ajouter à son portfolio. Ok, google le fait aussi, mais ca n'a rien d'une signature de google.

Et sinon, t'es vraiment gonflé. Y'a pas si longtemps, tu cassias les couilles de tout le monde à répéter que Mozilla est dépendante à 100% de google pour ses revenus, ca peut pas tenir, faut se diversifier, bla-bla-bla, moi je, yakafokon, jte jure, si j'étais CEO, ca serait pas la même histoire.
Et maintenant qu'ils se diversifient, tu viens nous peter les couilles à nouveau.
Putain, mais va mourir, quoi.

Bref, il faut aussi ne pas oublier qu'on ne doit rien à Mozilla non plus, et qu'on peut changer de service facilement.

Et ben change de service, et arrête de nous les gonfler.

Pour la dépolitisation, je trouve au contraire que ça se politise pas mal, cf les grosses boites "obligées" de s'afficher tolérantes, inclusives etc.

Bullshit. C'est juste une technique de recrutement.

Qu'on se comprenne bien, ils font réellement des efforts la dessus, mais ils ne le font pas par conviction politique. Plutôt tout simplement parce que le recrutement des gens talentueux est un enfer, que bosser pour apple ou google, c'est kifkif bourricot, et que lesdits gens talentueux choisissent doncleur employeur sur des critères périphériques. Y'a 10 ans c'était la cantoche et les babyfoot dans le bureau, maintenant que c'est devenu standard, on se rabat sur la diversité au boulot. Dans 10 ans, quand on aura enfin éradiqué les brogrammers facon Uber, ca sera autre chose.

Vous êtes chiants : j'attendais de la contre-argumentation, et je me retrouve avec :

Contre argumentation a quoi? Ton journal ne dit pas grand chose à part "bou mozilla pas bien caca", et n'explique pas non plus pourquoi le but de cette acquisition devrait être d'envoyer un message positif aux libriste. J'ai envie de faire mon zenitram et de te répondre "si tu veux envoyer un message positif avec une acquisition, fait le avec ton propre fric, Mozilla ne te doit absolument rien".

Mozilla a acheté 17 millions d'utilisateur, une marque, une équipe avec un savoir faire et (je l'imagine en tout cas) un business profitable.
Savoir si le code source initial est ouvert ou fermé, on s'en contrebalance. La qualité technique ne joue que tres peu dans les acquisitions, ce qui est recherché c'est soit un savoir faire (aka acqui-hire), soit du temps (couper tout le temps de dev grâce à un produit existant), soit les 2.

La morale, c'est que si t'es une boite de service et que tu veux te faire racheter (et gagner au loto des startups si prisée a San Francisco), faut d'abord bosser comme un turc, et ensuite soit être tres bon, soit avoir du succès auprès du public. La licence du code n'est qu'un détail technique don tout le monde se tamponne, mais d'une force…

Plus que diminuer les chances de coups de mains, ce fil est assez délirant.
On va réécrire ce truc, faire notre propre bug tracker, la chaîne de compilation a pas l'air piquée des hannetons, une architecture basée sur de l'ipc pour android (wat), et des blagues du genre "Y'a outil de compilation, mais trop complique, donc ya un outil pour utiliser l'outil, mais ca reste compliqué".

Je veux pas être méchant, mais quand les contributions manquent et que le projet est tenu à bout de bras par une seule personne, la priorité est de recruter (et donc de virer tout ce qui est un frein au recrutement, cf ce que dit dzecniv), et ensuite de limiter le scope pour pouvoir continuer à releaser fréquemment.
Penser ecrire son propre bugtracker et batailler contre un système de build ne me paraissent pas aller dans la bonne direction. Pour être tout à fait honnête, même avec une armee de contributeur, j'ai du mal à comprendre ce qui peut pousser qui que ce soit à écrire son propre bug tracker ('fin a part ceux dont le boulot est de faire des bug trackers, évidemment).

Mouaif.
il a écrit qq chose de tres long, pour dire en gros "git est pas vraiment affecté, mais en fait si, on a un patch, mais il est pas encore release".
Ce que j'en retient c'est qu'il est tout à fait possible de modifier un commit dans un repo sans casser aucun sha dans l'arbre, ce qui est quand même assez vilain: prend un commit suffisament vieux pour que personne n'y fasse attention, modifies le code pour introduire une faille subtile (du genre de heartbleed), ajoutes y un pdf, potentiellement cache (dot file), génère ta collision et paf le repo.

Sur un repo suffisament gros, c'est tres probable que personne ne remarque le fichier supplémentaire, et si la faille est un débordement de tampon subtile, ca se remarque pas non plus.

Ca fait un peu bizarre de voir Linus dire ca, après l'avoir entendu répéter pendant des années "git est chanmé parce que sha-1 garantit l'intégrité de l'historique".

Comment tu fais pour réfléchir quand t'as pas de données, que tu connais pas le marche et que le produit que tu crees n'existe pas (et donc tu ne sais pas comment il va être reçu, ni s'il répond correctement au probleme, quand tu ne sais meme pas précisément quel problem tu essayes de résoudre)?
L'experience et la connaissance du milieu, ca donne un bon point de depart, mais au final, ca reste surtout une opinion.

L'idee, c'est que quand tu connais mal ton marche, plutôt que de faire un pari a s'engager dans des designs couteux (produit et ingénierie) sur plusieurs années, autant tater le terrain avec un proto rapide qui coute peu et t'apprends beaucoup. Et tu revisite constamment la direction de ton produit.

Encore fois, ca s'inscrit dans un process exploratoire. C'est utile quand t'as une forte incertitude sur la direction précise du produit. Et quand ton marche est tout nouveau et est mal connu. Une enorme partie de l'informatique/services en ligne grand public tombe dans cette catégorie, vu que cette industrie est tres jeune et évolue a la vitesse de l'eclair au galop.

De plus si tu ne sais pas ce qu'il faut faire, comment tu sais que tu as le temps?

Justement. La philosophie est que quand tu ne sais pas grand chose de ton produit, ni de ton marche, un des trucs les plus urgents et importants a faire est de comprendre ton produit et ton marche. C'est urgent – il faut le faire la main'nant toussuite, et c'est tres important – la survie de ton produit en depend fortement.

Un point central dans cette stratégie est aussi que, aussi doué soient les product managers, ou utile soient les session d'user testing, absolument rien ne remplace le feed-back de vrais utilisateurs qui utilisent vraiment le produit pour de vrai.
Plutôt que de tergiverser pendant des heures pour savoir si #feature doit marcher comme ci ou comme ca, tu fait un proto rapide qui te donne une réponse (ou un bout), et tu corriges le tir.
Tout l'art tient dans la créativité de faire des protos qui tiennent la route (faut pas prendre les gens que pour des cons), et pour les ingénieurs de branler le tout pour que ca soit maintenable et évolutif (parce que, ouais, lean ne veut pas forcément dire travail de gougnafier).
L'elevator pitch ressemble en général à:
- la pire chose que tu puisses faire, c'est construire le mauvais produit
- le meilleur moyen de construire qq chose vite, c'est de trouver rapidement ce qu'il ne faut pas construire
- on pas la moindre foutue idée d'où on va ni comment on y va, alors on improvise et on se demerde (celle la, elle est de moi. Elle vend pas des masses, mais elle fait marrer les gens du milieu).

C'est une philosophie foutrement utile quand t'as une grosse part d'incertitude/exploration/créativité sur le produit, que t'as pas mal d'utilisateurs et que tu peux te permettre des écarts de conduite pour une portion d'entre eux.
D'où le fait que toute startup ayant du succès est rompue à ces techniques, vu qu'une startup à vachement tendance à tester de nouvelles idées de produit.
il se trouve que dans le logiciel, en général, ya vachement d'incertitude, mais pas forcément. Si ton boulot, c'est les logiciels de gestion de feuilles de payes, ya vachement moins d'incertitude quand même (ca veut pas dire que tu gagneras pas à ce genre de technique, mais c'est vachement plus risqué, et t'as beaucoup moins du retour sur investissement).

En passant,"chill" dans le contexte ci-dessus doit s'accompagner de la particule "out". Alors, si le créa pouvait se contenter de n'utiliser qu'UNE langue à la fois, je lui en saurais gré.

Non. Ca s'utilise très bien tout seul. Chill out, chillax, chill the fuck down, take a chill pill, où tout simplement "dude, chill".
Ca depend probablement des variantes d'argot locales, mais chill tout court est parfaitement accepté (en californien moderne en tout cas, aussi bien nord que sud).

Est ce que tu pourrais donner une definition de design? Parce que je suis pas sur ca veuille dire ce que tu pense que ca veut dire.
Par definition, le design c'est "qu'est ce que ca fait, et comment ca le fait". Le fait qu'un outil est efficace est la preuve qu'il a ete bien designe.

Ca a pas grand chose a voir avec le fait qu'il soit joli ou moche. L'esthétique est un concept subjectif qui évolue avec le temps. La qualité du design est intemporelle elle (en tout cas, sorti d'evolution majeur hardware/infrastructure en tout cas).
iMessage version iOS 6 est laid de nos jours, mais son design tient toujours autant la route.

ben si la vaste majorité des utilisateurs trouvent ca mieux et que ca repond mieux a leur besoin, ca me parait un peu être la definition d'etre meilleur, non?

Meilleur ne veut pas dire "totof2000 préfère cette approche", ca veut dire "on resoud le problèmes donne mieux que ce qu'on faisait ya 10 ans".
Si tu fais pas partie de la cible d'utilisateurs (dit autrement, si le soft resoud un problème que tu n'as pas), on s'en fout un peu de ton avis.

heu, ouais, je sais pas, 6 frames d'écart entre une action et le feedback visuel, perso je le remarque direct.
Je sais pas si c'est une déformation professionnelle, mais 100ms de lag perso je trouve ca énorme. J'ai le temps de faire une requête réseau et récupérer la réponse dans ce délai, c'est pas exactement ce que j'appelle rapide.

Argument facile.

A peu pres autant que de dire que le tollé sur le bandeau d'office (c'est de ca que je parle, et j'imagine toi aussi) n'était pas du a la resistance au changement.
Parce qu'en pratique, ca fait 10 ans qu'on a le bandeau, et visiblement tout le monde est content avec, et meme open office y pense.
Et du cote de chez apple, l'accent toujours ete mit sur une grosse barre d'outil en haut de la fenêtre, et de limiter le plus possible la nécessité d'utiliser des menus.

L'évolution d'office est le cas typique de résistance au changement.
Tout le monde à gueule, et un an plus tard, personne ne veut retourner à l'ancienne interface.

Une réactivité de 100ms n'est pas remarqué,

!!!
Tu remarques pas un délai entre 6 et 7 frames?

Une rapide recherche google m'apprends que winsxs utilise beaucoup de hardlinks, et qu'Explorer compte les hard links à chaque fois qu'il en trouve un.
Donc en gros, oui, Explorer va reporter une taille farfelue.

L'intérêt de docbook est qu'il structure les métadonnées de facon standard, et facile à extraire.
L'idée c'est de constituer une base de données indexées sur les auteurs, les références, citations etc, y comprit entre document. L'idée étant de pouvoir trouver les articles citant un article donne, ou tous les articles auquels jean duschmol a contribué, ce genre de choses.
T'ingeste les docbooks, tu remplit ton index, tu cherches et derrière t'as des feuilles xslt pour rendre les documents en forme présentable. Tout en un ('fin sauf le moteur de recherche, mais bon on va pas pousser mémé dans les orties quand même).

Markdown et ses dérives sont des formats de mise en page. Tu peux pas en extraire les métadonnées, ou en tout cas, elle n'ont aucune semantique.

Je demande juste publiquement pourquoi,

Et si tu leur posait la question directement, plutôt que d'écrire des pavés ici? C'est des ricains, ils lisent pas linuxfr, c'est aussi pertinent que de demander à ton voisin pourquoi Trump ne veut pas publier ses feuilles d'impôts.

flash n'est pas mort

Mouais. Il est pas supporte sur iPhone, iPad, ni sur android. Ca l'élimine de base pour tout site grand public.
Reste donc:
- les qq sites grand public qui n'ont pas ete mit a jour depuis 5 ans,
- les niches ou flash est plus adapte qu'html 5 (a supposer que ca existe encore en 2017),
- les qq applis pros qui ont ete code en flex ya 10 ans et qui n'ont jamais ete mise a jour

la premiere categorie a probablement deja subie une telle chute de traffic qu'on doit pouvoir virer le "grand" de "grand public", la deuxième est par definition une niche, et la troisième a jamais ete bien grande.

ps: je sais pas pour toi, mais rutube.ru marche visiblement bien sur mon safari sans flash.

He ouais!
Ca fait 15 ans que je l'entends celle la, que staroffice, pardon openoffice, pardon libreoffice est aussi bien que word.
Sauf qu'en général, ca veut dire "aussi bien que le Word d'il ya 5 ans", que c'est pas totalemenr vrai, et que pendant ces 5 ans, word a continué d'évoluer.
En l'occurrence, les suite offices migrent en ligne, et je voit pas grand chose la dessus pour libre office (à part collabora qui me tackle direct à la carotide avec une image docker et un reverse proxy apache à configurer, avec support ssl sivouplait, classe).

Le pire dans tous ca, c'est que les suites en lignes avaient une barre vraiment tres basse au début niveau édition (et sont toujours tres limitée d'ailleurs). Sachant que c'est la ou ms excelle (haha) avec 30 ans de features, y avait réellement moyen de faire qq chose. Mais non, le libre à préféré faire le suiveur, et traduire les commentaires d'oo de l'allemand vers l'anglais pendant ce temps la.

si tu veux pas vendre, c'est la meilleure approche

Bopf. Je bosse dans le milieux des applis mobiles depuis qq années déjà, et ce qui me fait fuire c'est pas tant le CPU, mais:

• le support software: les applis tierces qui m'intéressent ne sont pas dispo. En tant que dev, faudrait que je jette un œil à leur apis, mais Apple a mit la barre tres haut après 10 ans d'iteration sur leur plateform, ca devient difficile de convaincre des devs expérimentés d'aller ailleurs
• le matos périphérique: qualité de l'écran, TouchID, truc magnétique qui allume l'iPad quand tu l'ouvres, durée de la batterie, qualité de construction, durée du support soft, et durée de vie générale du matos (je croise régulièrement des gens avec un ipad 1 dans Bart, et j'ai passé moi même un week end avec un ipad 1 récemment, ca tient toujours la route pour un usage léger. Un ipad 2 ou 3 sont toujours tres utilisables, et ont entre 4 et 5 ans quand même

Ton CPU, j'ai pas la moindre idee de ce qu'il vaut, et je m'en cogne. Je confonds régulièrement les générations de CPU apple, et je suis même pas sur lequel est dans mon air 2 sur lequel j'écris ce message, Pour être honnête, je sais pas combien de ram j'ai dans mes iTrucs, ni sur mon laptop, et je suis incapable de te dire si le CPU de mon laptop est bon ou mauvais. Et je sais meme pas si mon gpu dans mon laptop est un nvidia ou un amd.
Ca fait longtemps que les specs "pures" sont plus tres pertinentes, tant qu'elles sont suffisamment décentes.

La mauvaise nouvelle pour Ubuntu c'est que le marché d'os pour tablettes et téléphones est verrouillé: apple se taille la part du lion et rafle la majorité des profits, google vise la collection de donnees à tres large échelle, au détriment de ses partenaires. Sorti de ces 2 la, point de salut, a moins de taper dans la microniche (et encore, même dans ce cas, tu vas partir sur du android, potentiellement customisé).
Même Microsoft ne s'en sort pas, avec pourtant toute sa force de frappe marketing, commerciale et d'ingénierie.
Travailler sur Linux sur les tablettes, c'est aussi pertinent que de travailler sur Linux sur le desktop y'a 10 ans: c'est une impasse. les 40 dernières années ont marche comme ça: un nouveau marche se fait rafle pour une ou deux boîtes, le marché reste verrouillé jusqu'à la prochaine vague.

J'espère qu'un jour les linuxiens comprendront qu'il faut arriver le premier sur une nouvelle vague avec un produit suiffisament bon qui peut évoluer suffisament vite, plutôt que de se pointer la gueule enfarinée avec des années de retard.

Ce n’est pas le cas de soap (par exemple). La compression HTTP ne s’est pendant très longtemps faite que pour la réponse (je crois que désormais il y a aussi des choses pour le faire sur la requête, mais je ne suis pas sûr que ça soit tout standardisé). J’avais développé des extensions pour de la compression de requête, vers la fin des années 2000, il n’y avait à l’époque rien de standard. Ça fonctionnait bien, mais ce n’était plus du tout interopérable, du coup (on s’en foutait car on maîtrisait le client et le serveur, mais de manière générale c’est un manque).

J'ai du mal à comprendre, soap pass par http, qu'est ce qui t'empêche de compresser la requête et mettre le header content encoding qui va bien? Et en quoi c'est pas standard? Et dernièrement, en quoi json est épargné?

Quand tu t'appelles google, et qu'un rapport 2 ca veut dire des centaines ou milliers de machines en moins, ca chiffre vite :)

Et ce n’est pas fait pour me rassurer.

Mouais, si y'a un milieu où les hommes sont très peu fiables, c'est bien l'aéronautique commerciale.
Entre l'échelle et la complexité des machines, et le fait que les sens humains sont tellement peu adaptés à ce milieu qu'ils en deviennent presque inutile, une machine fait un bien meilleur boulot.

Le vol vfr (visual flight rules), ca marche sur un petit coucou dans de bonnes conditions météo. Ne serait ce que percer une couche en vfr peut tres vite devenir tourner à la catastrophe: la vue est inutile, et l'oreille est tres vite confuse. Des que ca se corse, les vfr sont cloués au sol, pour une bonne raison: c'est beaucoup trop dangereux pour eux.

Je me rappelle plus des détails du rapport sur le Paris/rio, mais si je ne m'abuse, le bea a mit la cause sur le copilote qui a ignoré l'alarme de décrochage et continuer à cabrer comme un cannu, ignorant ce que l'avion et le commandant de bord lui disaient. Ce qui illustre au passage bien ce que je disait plus haut à propos des sens qui sont majoritairement inutile: l'avion était grosso modo en chute libre avec une assiette à cambrer, et le copilote ne s'en est pas rendu compte du tout.

J'ose imagine que l'Elysée a le bon gout d'utiliser un .fr quand meme.
Et aussi d'avoir le bon gout de retourner autre chose qu'un 200 OK sans contenu :)