Croconux a écrit 1196 commentaires

Mais elle n'est pas copine compatible donc c'est un petit sacrifice pour la survie de l'espèce.

La plupart des web polueursdesigners ont tendance à toujours forcer l'utilisation de la toute dernière version parce que forcément elle doit être mieux puisque c'est la dernière. Lorsque flash 10 est sorti, beaucoup sites se sont retrouvé "auto-nettoyés" par le flash block officiel "Une version plus récente est nécessaire. Voulez-vous l'installer ?". Bah, bon.

Je ne suis pas trop inquiet concernant les anciens contenus. Flash, c'est un peu du jetable. Des animations en Flash 7, il ne doit pas en rester beaucoup. Rapidement, le tape à l'oeil n'est plus suffisamment tape à l'oeil donc ils faut faire une nouvelle animation encore plus flashy. La pertinence d'un contenu est souvent inversement proportionnelle à son degré d'eye candy.

e=M6 a cessé d'être une émission scientifique

Je n'avais plus vraiment regardé cette émission depuis plusieurs années et je suis retombé dessus il y a quelques temps. Ca m'a fait un choc : Un belle succession de publi-reportages à peine voilés (sans mauvais jeu de mot). Un émission sur la nutrition, particulièrement des enfants, avec une magnifique visite de la plus célèbre marque de cochonneries pur sucre/colorant/émulsifiant/gomme xantane/substances non identifiées... Mais on ne site pas la marque, attention, on est des gens sérieux, nous. Le "reportage" se terminait par une phase comme "voilà, vous savez comment faire plaisir à vos enfant". Et contrairement aux "vraies" pub, pas de message "évitez de manger trop gras ou sucré". Pour reprendre le slogan d'une autre marque (on n'est plus à ça près) : Que du bonheur. Franchement, Mac Lesggy n'en sort pas grandi.

Le refus d'Apple du flash n'a pas grand chose à voir avec l'ouverture. Ce n'est qu'un prétexte. Apple veut juste contrôler à 100% sa plateforme. Aujourd'hui le seul moyen d'installer une appli sur un iPhone c'est de passer par leur boutique. Flash c'est un peu une plateforme sur la plateforme. Une fois Flash installé, plus besoin d'obtenir l'agrément de sa seigneurerie Jobs pour sortir une appli pour iPhone. Plus besoin de payer la dîme à sa sainteté si on fait une appli payante. Non, on peut proposer son appli directement sur son propre site, sans intermédiaire. En somme tout ce qu'Apple ne veut pas.

parce « ça ne coûte rien » d'envoyer un email, d'attendre puis de refaire une autre transaction

Sans compter que pendant ce temps, la maison fait crédit gratos. Free aussi a des factures à payer à échéances fixes. Si tout le monde se donne un peu de temps pour payer, ça va coincer au niveau trésorerie.

Il y en a qui ont essayé. J'ai vu un gars il y a quelques temps tenter d'amadouer un contrôleur dans un bus. Les temps sont durs, toussa... le tout un iPhone à la main. Forcément, pas trop crédible.

--nodeps --force

Et après c'est la faute de RPM...

Ce type de tutoriel pose à mon avis quelques problèmes. Tout d'abord, au niveau bande passante ça pèse. Avec les connexions actuelles, les gens semblent supposer que ça n'a aucune importance mais quand on y accède depuis une connexion un peu plus lente (hot spot, 3G+) ou même via une connexion partagée entre pas mal de monde, comme c'est souvent le cas en entreprise, ça rame, ça saccade, bref c'est insupportable. Pour limiter la taille de la vidéo, le débit est souvent faible d'où une qualité à chier, du texte limite illisible (pour du code ça la fout mal). Autre soucis, il faut du son. Bah oui c'est con mais au boulot il faut avoir un casque sous la main (souvent pas de haut parleur et même sans ça difficile de faire chier tout le monde pour lire sa petite vidéo).

Un point qui ne gêne peut être pas tout le monde, la plupart des tutoriels sont en anglais et il faut être plutôt fluent pour suivre un irlandais ou un texan qui fait une présentation. Pas de sous titre, si on rate un bout de phrase on est paumé. Impossible d'utiliser des outils de traduction en ligne. Au niveau accessibilité, c'est le niveau zéro. Impossible de faire un copier coller du code pour le tester. Ne pas oublier non plus les moteurs de recherche. Un tutoriel texte sera facilement indexé. Une vidéo pour un moteur c'est un gros blob. Si je cherche une info sur l'utilisation de telle fonction, aucun moteur ne me trouvera cette vidéo même si elle en parle.

Ca semble surtout tendance en ce moment de mettre des vidéos même si ça n'apporte pas grand chose (c'est trop waibe two point zero). Certains vont même jusqu'à se filmer en train de parler façon JT, sans tableau ou autre info utile derrière, non juste le gars qui parle devant la caméra. Il y a des cas où une vidéo est plus parlante que du texte mais pour du code, ça me semble peu approprié.

C'est une manie de pas mal de sites, surtout français : Il n'autorisent que quelques domaines qu'ils considèrent valides. Tout le reste est refusé. Certains n'acceptent même que les comptes des FAI (il y a des gens qui s'en servent ?), ils refusent même les comptes gmail, hotmail, etc. "C'est trop facile de créer un compte bidon". Mais s'ils ne comptent pas pourrir (ou vendre) mon adresse qu'est ce que ça peut leur foutre ??

Pour cela, il faudrait contrôler toutes les adresses à la main. Si je crée des adresses du type "moi.pour.amazon@chez.moi", "moi.compte.fnac@chez.moi", à moins de contrôler chaque adresse une par une, difficile de deviner ce qu'il faut retirer. Et puis sur des centaines d'adresses, les spammeurs ne vont pas s'emmerder pour la moule qui a pris la peine de protéger sa vie privée.

En même temps je ne suis pas sûr que ça change grand chose. Le gouvernement a déjà montré qu'il s'asseyait allègrement sur les procédures, les lois, les décisions de la Cnil/du conseil constitutionnel quand ça l'arrangeait. Un loi dont on lançait déjà le déploiement avant qu'elle soit votée (ça passera de gré ou de force), un logiciel de "sécurisation" toujours aux abonnés absents mais ça n'empêche pas de commencer. Comment prouve-t-on sa bonne fois si la seule "preuve" reconnue n'existe pas : On s'en fout, faut frapper vite et fort (sur qui, on s'en fout aussi, il faut faire peur, c'est tout).

Je pense que ça va se terminer par "on va demander l'avis à posteriori" et il sera favorable (sinon des têtes vont sauter). C'est beau la ChineFrance.

Sinon dans la continuité des trucs plus que louche, outre le recyclage d'Albanel à France Télécom (sans doute un engagement du "Grenelle environnement"), il y a la dernière polémique à propos de brevets sur le marquage et la détection de fichiers déposé par... des conseillés d'Albanel, ceux même chargés de plancher sur cette partie du dossier. Il n'y a pas de mal à se faire un peu de thunes au passage. Franchement, ça me donne de plus en plus envie de gerber. Ils ne se cachent même plus pour faire leurs magouilles. Quand un gus est pris en plein conflit d'intérêt, ça se termine toujours par un démenti du genre "M.Z est un homme intègre... aucun problème de déontologie...". Circulez, il n'y a rien à voir.

Le monde de l'informatique suit malheureusement l'évolution de télés... sans tenir compte du fait que les contraintes sont totalement différentes. Une télé format cinéma c'est sympa mais un écran au même format c'est galère pour travailler.

Les interfaces ne sont pas du tout adaptées. On a souvent des menus, barres d'outils, etc en haut et en bas donc on perds encore de la place. Le pire est que ça fait un bon moment que les écrans suivent cette tendance (16:10 et maintenant 16:9) et rien n'a été fait. Je comprends que le monde Windows soit à la traîne (les releases sont très espacées) mais le libre pourrait dans ce domaine être pionnier. On peut par exemple prévoir le positionnement des outils sur les côtés ou au moins les rendre déplaçables. Si les modifs sont prévues au niveau toolkit (GTK/QT), il devrait suffire de recompiler toutes les applications pour bénéficier des améliorations.

Autre soucis lié aux écrans larges, lire du texte comportant des lignes très longues est pénible. Du coup pas mal de webpolueursdesigners figent leur interface en largeur. Mauvaise pioche. A leur décharge, il ne sont pas les seuls à blâmer. Les outils et techniques sont rudimentaires. La conception des CSS est de mon point de vue un désastre complet. Faire une mise en page relativement classique (barre latéral, pied de page, fluide/fixe, etc) est incroyablement pénible alors que c'est le b-a-ba. Il suffit de voir le nombre de sites qui expliquent les astuces pour parvenir à faire une mise en page basique.

Il suffit de regarder ce qui se fait dans les autres formes de publication. On n'imprime pas les livres/journaux/magazines en format rouleau de PQ. Pour profiter de la largeur de la page on place le contenu sur plusieurs colonnes. Ca permet par exemple de placer une image/un graphique/un code source à côté du texte qui va avec. Pourquoi nos webbouletsdesigners ne font-ils pas pareil ? Ca demande un peut de boulot (encore une fois rien de prévu dans les CSS) mais c'est faisable. Un amis avait fait une bidouille qui permettait d'afficher différents morceaux d'une page soit côte à côte si la largeur de la fenêtre le permet, soit à la suite sur un petit écran. En redimensionnant la page, on passait dynamiquement de l'un à l'autre. Evidemment, il fallait un peu de javascript pour permettre le comportement dynamique.

Dernier problème lié aux écrans larges : La résolution. On est encore une fois bridé par la télé. Au début des écrans LCD, les résolutions ont augmenté gentiment mais c'est fini. Maintenant c'est 1920x1080 pour tout le monde. Personnellement, j'ai un écran 1920x1200 mais maintenant les nouveaux écrans ont moins de pixels. 24/26/28 pouces, tout le monde à la même enseigne : Format fullhd. On se retrouve avec de grands écrans munis de pixels énormes. La classe... "Mais c'est le format cinéma, chérie".

Alors on doit aussi réécrire le noyau en shell parce que sinon "on se retrouve avec des trucs binaires dont personne ou presque ne comprends rien au fonctionnement" ? Les scripts d'init, on n'a normalement pas besoin de la bidouiller à la main tous les 4 matins. Et puis entre nous un code C me semble plus lisible que du shell qui permet très facilement de se prendre les pieds dans le tapis sans s'en rendre compte (espaces significatifs, etc).

Avec une bonne ergonomie, le besoin d'une bonne doc devient moins pressant.

L'ergonomie et l'intuitivité ne sont pas la même chose. Pour prendre un exemple qui touche certains ici : Le clavier bepo est conçu pour être ergonomique (minimiser l'effort) mais il n'est pas intuitif (il demande un temps d'adaptation). Pour l'interface d'un logiciel, c'est pareil. Certains logiciels permettent de rapidement trouver ses marques mais réclament un grand nombre d'opérations (menu, boite de dialogue, etc). A l'inverse d'autres sont plus austères au début mais très efficaces une fois qu'on a les a en main.

L'ergonomie est relative. Tout dépend du public auquel on s'adresse, des codes/habitudes du métier/domaine. Un logiciel de compta par exemple peut très bien sembler imbitable pour le quidam moyen mais complètement logique pour la personne dont c'est le métier parce qu'il présente les informations comme les comptables on l'habitude de les écrire. Si on conçoit ce genre de logiciel en fonction des critères d'un individu lambda (non comptable), le comptable va être paumé.

Tout ça pour dire qu'un logiciel, même ergonomique et intuitif , à besoin d'une doc, éventuellement intégrée au logiciel ou l'on peut rechercher comment faire telle au telle action.

Parce que 80% des utilisateurs n'ouvrent pas une doc.

Peu de gens lisent la doc _avant_ d'utiliser un logiciel mais lorsqu'ils rencontrent une difficulté et ne trouvent pas comment faire quelque chose il se tournent vers la doc. Un peu comme quand on achète un nouvel appareil. La plupart des gens commencent par le brancher et trifouiller les boutons puis ouvrent finalement le bouquin quand ils se rendent compte qu'il n'arrivent pas à régler l'heure dessus.

Il y a effectivement du boulot concernant la doc utilisateur. C'est souvent du au fait que beaucoup de développeurs bénévoles développent avant tout pour eux même et que leur code n'a pas forcément vocation à être utilisé, ou en tout cas pas par un grand nombre de personnes (et pas Mme Michu).

Sur un projet qui fait beaucoup d'audience ou pour lequel on est tenu (commercialement) de faire du support, documenter est une évidence. Quand on en a marre de se prendre pour la 10e fois un bug qui n'en est pas un sur une fonctionnalité mal comprise, on met à jour la doc ou on ajoute une entrée dans la FAQ, ne serait-ce que pour se faciliter la vie et limiter le flux entrant. Dans la monde du libre, on est moins impacté. Les utilisateurs ont tendance à tester un logiciel et abandonner pour passer à autre chose s'ils rencontrent un problème. Ils sont peu nombreux à remonter des bugs. Du coup le développeur ne se rends pas compte qu'il y a un réel problème et comme il n'a pas de soucis, il ne change rien.

Il me semble que ça ne réponds pas au même besoin. Les outils cités permettent essentiellement de documenter une API via des commentaires dans le code. Il s'agit d'une documentation destinée exclusivement aux développeurs. Il y a d'autres niveau de documentation : Documents de design général et d'architecture qui permettent de comprendre la logique générale avant de plonger dans le code, et surtout la doc destinée à des non-developpeurs : Manuel d'utilisation, tutoriel, etc. C'est plutôt ce genre de doc que vise le projet présenté. C'est relativement proche d'un wiki avec avec export dans divers formats.

J'ai également un peu de mal à voir ce qu'apporte une distribution "100% francophone" par rapport à une distribution standard localisée. Est-ce que les autres locales ont été supprimées ?

Il me semble que 99.9% du travail sur une distrib est indépendant de la langue. Créer une distrib francophone, une distrib germanophone, etc c'est repartir de zéro pour changer 0.01%. Pourquoi ne pas mutualiser les parties communes ? Voire encore mieux : Remonter les contributions concernant la localisation aux différents projets concernés ?

Il y a un peu la même chose en C# avec les nullable types :

int? i; //Nullable int.
// i.HasValue() == false

i = 2;
i.Value; //2

C'est bien pratique notamment pour le classique tristate (vrai/faux/pas défini).

Pour la gestion du nul pour il y a aussi l'opérateur "??" (null coalescing operator)
Le second membre est exécuté si le premier est nul.

string s = null;
string s2 = s ?? "Rien"; // s2 == "Rien"
s = "Un truc";
string s3 = s ?? "Toujours rien ?"; // s3 == "Un truc"

Je me rappelle avoir lu un article sur une idée un peu voisine évoquée lors du dernier salon du livre. Il ne s'agissait pas de publicité mais d'informations contextuelles. Par exemple, on lit un livre dont l'action se passe dans un pays/une ville qu'on ne connaît pas bien, en "cliquant" (avec ses gros doigts sur un écran tactile) sur son nom, on arrive sur la page Wikipédia correspondante ou bien ça lance une recherche Google/Bing/etc sur le mot. Il pourrait aussi y avoir du contenu additionnel (des documents complémentaires ajoutés au livre). A mon sens, ça se rapproche un peu des reportages de fin d'épisode des cités d'ors.

Rien n'empêche de lire le livre sans s'en occuper mais quand on le relis pour le plaisir, on peut avoir en envie d'en apprendre plus certains sujets, de lire des commentaires de l'auteur (ce qui lui a donné telle idée, quelle autre fin il avait envisagé,...) un peu comme le making of d'un film. Tout changement technique ouvre de nouvelles possibilités. Tout dépend de ce qu'on en fait. Clairement un truc bardé de pub, ça n'intéresse personne.

La tu forces un peu le trait (définition d'un enum alors que dans le code d'origine les valeurs d'erreurs ne sont pas bornées, etc).

Sans exagérer ça donnerait plutôt ça :


if (do_step_1 () == FALSE)
{
    undo_step_1 ();
    return FALSE;
}

if (do_step_2 () == FALSE)
{
    undo_step_2 ();
    return FALSE;
}

if (do_step_3 () == FALSE)
{
    undo_step_3 ();
    return FALSE;
}

return TRUE;


C'est tellement plus compliqué ?

C'est justement le genre de chose qui m'a fait défaut récemment. Les paquets en provenance d'unstable ont tendance à passer rapidement dans testing et donc à remplacer les anciens paquets. Les miroirs font assez rapidement le ménage et si on se rends compte un peu tard qu'on à un problème de compatibilité avec la dernière version, pas de bol, impossible de rétrograder le paquet parce qu'il n'existe déjà plus sur les miroirs. Vécu avec xorg. Un casse tête pas possible pour retrouver les paquets de la version 7.4.

Tu as des sources pour affirmer tout ce que tu dis ?

Comme je disais, on a déjà parlé ici. Un petit tour par la boiboite "rechercher" donne :

http://linuxfr.org/~patrick_g/23109.html#774993 (Mailing list debian)
http://linuxfr.org/~abramov_MS/25233.html#864598 (Comparaison avant/après)

Je ne crois pas qu'ils se basent sur NV. Ils auraient bien du mal à en faire quelque chose. Le code était maintenu quasi exclusivement par des employés de Nvidia et il avait été (volontairement) obscurci il y a quelques années. On en avait parlé ici à l'époque. Des commentaires ont été retirés et a peu près toutes les constantes avaient été remplacées par des valeurs hardcodées en hexa sans la moindre documentation.

De plus NV ne gérait que la 2D, rien pour la 3D. Il n'était donc pas très utile aux développeurs. Nouveau le remplacera avantageusement pour tous ceux qui veulent un driver libre et qui n'ont pas vraiment besoin de la 3D. Par contre il est peu être un peu jeune et pas forcément bug free. De toutes façons, NV n'avait plus de raison d'être mais NVidia aurait peu attendre encore un peu.

Je ne suis pas spécialiste du droit canadien mais ça semble bien parti. Microsoft gagne du temps et essaie de trouver des vices de procédure mais sur le fond un marché public doit faire l'objet d'un appel d'offre et la procédure n'a pas été respectée. Ils ne peuvent pas dire le contraire. A moins d'une bourde juridique, je ne vois pas comment la plainte ne pourrais pas aboutir.

Si la procédure doit repartir de zéro, il est toujours possible que l'appel d'offre soit taillé sur mesure pour que seul Microsoft puisse y répondre mais après le bruit fait autour, ça ferait probablement jaser.

- le taux de chômage des femmes reste plus important

Ca n'est plus vrai depuis quelques mois. Depuis 2008, l'industrie lourde et le BTP ont licencié en masse. Ces postes étant très peu féminisés, le taux de chômage des hommes a bondi. Les femmes travaillant essentiellement dans le tertiaire (les professions médicales, la justice, et les services à la personnes en tête) elles ont moins été touchées par la crise.

- les jeunes filles ne sont pas orientées et/ou ne s'orientent pas vers les études d'informatique (seulement 10% des futures informaticiens belges sont des filles), pourquoi ?

Bonne question. Tu es probablement mieux placée que nous pour y répondre. Est-ce que tu as suivi un cursus d'informatique ? Sinon qu'est-ce qui t'en a dissuadé?