Je suis quand même très surpris! Pourtant il me semble qu'une base NoSQL orientée document serait très bien adaptée, avec une petite annonce = un document .
Je me demande ce qu'ils retirent de l'utilisation d'une base relationnelle a part le besoin d'avoir un très gros serveur?
Il existe par ailleurs une extension Firefox permettant de coller automatiquement la sélection courante dans une page d'un bloc-note afin de conserver ses sélections au fur et à mesure de la navigation, et d'en retrouver l'origine. Cette extension ne fonctionne pas telle quelle (problème de numéro de version max, mais en modifiant le fichier install.rdf du package zimcapture.xpi, cela fonctionne en tout cas sur Firefox 10.0.1;)
Pour résoudre le problème des montées de versions de Firefox, il me semble que le plus simple et de mettre son extension sur AMO (addons.mozilla.org) car la plupart des extensions ont leur numéro de version automatiquement augmentée lors d'une nouvelle version de Firefox. Je ne sais pas exactement ce qui conditionne cette montée de version: JS only, utilisation de Jetpack, autres?
Pour automatiser le parcours d'un site web depuis un navigateur, je te conseille d'utiliser Selenium RC (Remote Control) ou bien WebDriver (inclus dans Selenium depuis la version 2).
Tu disposes en plus de Selenium IDE, une extension Firefox pour faire du capture / replay qui est très utile avec Selenim RC, un peu moins avec WebDriver.
Techniquement tout est possible, c'est au niveau de la main d’œuvre/volonté que ça pèche.
Lancer autre chose la dilue.
Sauf si la base (le protocole X et son implémentation X.org) est la raison originelle du manque de main d’œuvre.
Je ne lis pas de travers. C'est tout de même un point important cité dans la partie "Pourquoi X n'est plus adapté". Par contre je n'ai pas encore pris le temps de parcourir les liens en référence. Ça me donnerait peut-être la hiérarchie des problèmes qui motive la création de Wayland.
Pour faire court: X embarque une tripotée d'API qui ne sont quasiment plus utilisées aujourd'hui. Elles étaient très utilisées et adaptées lorsqu'X a été créé, mais ne correspondent plus aux usages actuels (OpenGL). Beaucoup de ces fonctionnalités ont été sorties de X (gestion des fontes directement dans GTK ou Qt, KMS, etc.). Le problème c’est que pour qu'un logiciel puisse clamer être un serveur X, il doit implémenter toutes ces fonctionnalités obsolètes. Donc, a un problème d'architecture mentionné plus haut, s'ajoute un problème de conception qui n'est plus en phase avec son temps.
Comme avec tout logiciel devenu historique (legacy), on peut soit ne pas toucher beaucoup a son cœur et lui rajouter des extensions (c'est ce que l'on a fait jusque la avec X), jusqu’à ce qu'on le remplace, car trop lourd, trop cher, on peut faire mieux, etc.
Euh, je suis moyennement d'accord. Comme il le dit bien:
At the same time both Apple and Google have set some bad examples by building a number of WebKit-only demos that might be part of what lead some developers to conclude that only WebKit supports such features. That has also spilled over into the world of tutorials where even sometimes even standards advocates showcase -webkit in their sample code while ignoring -moz-, -ms- and -o-*.
Appelez ça gagner de la part de marché, appelez ça lock-in, mais oui ils ont une responsabilité la dedans. Laisser cette porte ouverte, a laissé certains développeurs peu soucieux ou ignorant des standards du web s'engouffrer dedans sans se poser aucune question.
Je comprends les besoins des navigateurs de se différencier et de proposer des innovations, mais je regrette qu'ils ne jouent pas le jeu des standards en premier. Lâcher une implémentation non spécifiée dans a la nature tout en faisant de la communication sur ces nouvelles fonctionnalités super-cool sans communiquer les habituels garde-fous (EXPÉRIMENTAL, etc.) montre une responsabilité.
Mozilla est bien plus vertueux lorsqu'ils publient publiquement des specs pour les nouvelles fonctionnalités, lorsqu'il les poussent dans les comités du W3C (ou du WHATWG précédemment) et ainsi de suite. Si tous les éditeurs faisaient la même chose, on n'en serait pas la.
Bref, je refuse de dire que le problème est uniquement du cote des développeurs web. C'est trop facile de dire ça.
Ce n'est pas parce que la situation actuelle est mauvaise que l'on doit la laisser se pourrir encore plus.
Si a partir d'aujourd'hui, toute nouvelle fonctionnalité est "protégée" d'une libre utilisation dans la nature comme Manuel Vonthron et Daniel Glazman le proposent, alors on va s'épargner le besoin de refaire une telle campagne de comm' dans le futur.
Reste a convaincre tous les éditeurs de navigateurs. Ce ne sera pas une mince affaire. Mais chat échaudé craint l'eau froide? S'ils n'aiment pas la situation actuelle, alors ils vont faire quelque chose pour 1) qu'elle ne se reproduise jamais, 2) qu'elle se résorbe petit a petit.
Par contre l'attitude consistant à culpabiliser les développeurs alors qu'ils utilisent des extensions implémentées par les éditeurs (eux-mêmes membres du W3C) est d'une lâcheté incroyable.
Ce n'est pas parce que les éditeurs font partie du W3C qu'ils soumettent tous leurs travaux au W3C, loin de la. Tu te heurte a la main droite qui ignore ce que fait la main gauche.
Tu as raison: les éditeurs font tout pour que leurs travaux soit utilisables, mais ils ne font pas tout pour que ce soit standardisé, loin de la.
Maintenant, je ne comprend pas ta défense de certains développeurs web qui font des sites webkit-only tout comme l'on avait des sites IE-only. Ce ne sont quand même pas les éditeurs de navigateurs qui ont forcé les développeurs a faire ça?
Alors je maintiens que le problème est double, et c'est exactement ce que Daniel Glazman dit aussi (respire un coup et relis ce qu'il a écrit). L'appel du W3C CSS Working Group demande a TOUT LE MONDE de faire un effort pour stopper cette situation: les éditeurs de navigateurs, les développeurs web et les utilisateurs de sites web.
Le mécanisme des extensions spécifiques au navigateur ont été créées pour permettre de tester les propositions de fonctionnalités faites au W3C CSS Working Group. Le problème c'est que ces propriétés sont accessibles dans les versions stables des navigateurs sans rien faire de spécial. Daniel Glazman a déjà dit que c’était un problème et que ce serait bien mieux si ces propriétés n'étaient accessibles que lorsque l'on active une configuration spéciale.
Les développeurs web se sont emparés de ces possibilités et ont commencé a créer des sites webs avec elles. Malheureusement ce qu'ils n'ont pas compris, c'est que ces fonctionnalités sont EXPÉRIMENTALES, parfois propriétaires car non soumises au W3C, parfois refusées par le W3C, parfois sous spécifiées, souvent pleines de bugs, …. Bref, autant je comprends leurs besoins, autant ils ont joué avec le feu surtout lorsque certains n'utilisaient que les extensions spécifiques a webkit.
Daniel Glazman fait parti du camp des éditeurs de navigateurs puisqu'il travaille énormément sur et autour de gecko.
Bref, le W3C CSS Working Group demande:
aux éditeurs de fournir les specs des extensions au W3C.
aux développeurs web de faire des sites web qui marchent avec tous les navigateurs (le plus possibles en tout cas) et pas seulement webkit, en utilisant les préfixes des autres navigateurs et les propriétés non préfixées lorsque cela est possible.
aux développeurs web d'arrêter de faire des sites web qui refoulent toute personne n'utilisant pas IE/Firefox/webkit.
aux utilisateurs de site web de se plaindre aux sites webs qui ne fonctionnent qu'avec un navigateur et de ne pas recommander de tels sites.
Voila le nouveau business des opérateurs internet
Tu payes et encore derrière on t'exploite et te réexploite.
C'est du super foutage de gueule.
Si au moins c’était gratuit on saurait pourquoi ils font ça.
Il me semblait avoir lu que les applis Google (Maps, Navigation, Gmail, etc.) ne sont pas libres. Mais ce n'est qu'un vague souvenir et ça reste à vérifier.
Est ce que Gradle correspond mieux a Scala? J'ai lu du bien de cet outil de build pour les langages de le JVM autres que Java. Gradle est un mélange entre Maven et Ant. Il te propose des conventions précises pour Java (tout comme Maven), tout en étant beaucoup plus facilement configurable et il est plus facile d'écrire des taches custom dans les fichiers de build.
Par exemple, tout besoin non conventionnel avec Maven va nécessiter l’écriture d'un plugin Maven (Bah!), il est difficile de changer le comportement par défaut, XML c'est sympa un moment mais ça devient quand même lourd au bout d'un moment.
Gradle c'est:
* la possibilité de scripter son build en Groovy dans le fichier de build,
* la possibilité de changer le comportement par défaut de certaines taches,
* des notations compactes pour décrire les dépendances.
* un outil de build pensé pour construire des projets codé en multi langages.
Malheureusement je ne l'ai pas encore essayé, et je suis sur que le revers de la médaille est que les fichiers de builds peuvent vite devenir illisible si un goret est passé par la. Alors qu'avec Maven, le fichier XML reste a peu près potable en tout circonstances (enfin, pour du XML quoi).
Bref, je conseille de jeter un œil sur Gradle aui a l'air très intéressant.
La suggestion d'un return unique par méthode est bien pour des langages comme le C++ qui vont générer une tétra chiée d'appels aux destructeurs pour chaque return (quoique, j’espère que les compilateurs ont amélioré ça de nos jours?). Par contre, pour des langages comme Java, C#, Python, Perl, PHP, etc. ça ne sert strictement a rien et ça nuit a la lisibilité du code.
Bof pas vraiment dans mon souvenir pas si vieux.
En même temps, je ne rappelle pas avoir eu de cours expliquant bien les tests unitaires avec TP, sinon, je peux te dire que j'aurais perdu moins de temps pendant mes études. Pareil pour l'utilisation du logging au lieu des bons vieux system out dans du code multithreadé, bref, on apprend beaucoup de théorie, mais de tous petits ateliers de génie logiciel (UML ne compte pas) avec les bonnes pratiques ne ferait pas de mal du tout.
JaCoCo a été démarré par le gars qui maintient le plugin Eclipse d'Emma appelé EclEmma. Il avait plein de rapports de bug pour Emma, mais il n'y avait aucun mainteneur et pas de tests unitaires non plus. Alors il a décidé de réécrire une librairie pour vérifier la couverture de code.
Voila comment JaCoCo est né, c'est une base de code complètement différente, donc ce n'est pas la suite d'Emma, mais un remplacement total.
Bah c'est un peu comme la sécurité. La plupart s'en foutent royalement jusqu’à ce que cela crée des problèmes. Et la il faut tout corriger tout de suite. Mais il n'y a plus personne pour payer, alors que pour ajouter des fonctionnalités inutiles, la il y a plus de monde.
Une image MNG ne peut pas être lue par un navigateur supportant les images PNG. Du coup, il n'y a pas de possibilité d'adoption progressive de ce format sur le web. Ce défaut ajouté a la taille du code requise pour gérer le MNG (commentaire ci-dessus) a poussé Mozilla a inventer l'APNG qui n'a pas rencontré beaucoup plus de succès.
Ah bon? Bah, c’était la préhistoire :)
Je suis arrivé a la programmation lorsque Java 1.4 était la.
Mais certains projets Apache on la fâcheuse manie d'absolument vouloir compiler leur code avec Java 1.2 ou mois. Y a-t-il vraiment encore des gens qui compilent du code avec Java 1.2 ou moins et qui ont besoin que leur libs soient compilées avec cette même version?
La principale raison pour laquelle il est déconseillé de ne pas accéder directement aux champs est justement parce qu'il n'est pas possible d'en faire des méthodes par la suite sans changer la signature, et donc devoir modifier tous les appels.
Non, ce n'est pas la raison. La raison est qu'un accès direct aux champs n'est pas polymorphique (c'est même statique comme le précise Buf) et bloque donc toute réutilisation de ce code avec de la programmation objet, ce qui peut être très gênant et conduire a des copier coller (quelle monstruosité!).
[^] # Re: question bête
Posté par djano . En réponse à la dépêche Migrer de Oracle à PostgreSQL : Ora2Pg. Évalué à 2.
leboncoin.fr utilise une BD relationelle?
Je suis quand même très surpris! Pourtant il me semble qu'une base NoSQL orientée document serait très bien adaptée, avec une petite annonce = un document .
Je me demande ce qu'ils retirent de l'utilisation d'une base relationnelle a part le besoin d'avoir un très gros serveur?
[^] # Re: Wow !
Posté par djano . En réponse à la dépêche Version 1.0 de Julia. Évalué à 3.
N'hésitez pas a leur soumettre vos améliorations.
Avec un peu de chance ils ne sont pas sectaires et vont les intégrer :)
[^] # Re: Beau projet!
Posté par djano . En réponse à la dépêche Version 1.0 de Julia. Évalué à 3.
Il faudrait déjà que Numpy soit pleinement fonctionnel avec Pypy.
Voir:
https://linuxfr.org/news/l-interpreteur-python-pypy-1-8-est-sorti
http://buildbot.pypy.org/numpy-status/latest.html
[^] # Re: alternative
Posté par djano . En réponse à la dépêche Zim, le wiki de bureau est sorti en version 0.55. Évalué à 2.
Il y a aussi BasKet Note Pads.
Pour résoudre le problème des montées de versions de Firefox, il me semble que le plus simple et de mettre son extension sur AMO (addons.mozilla.org) car la plupart des extensions ont leur numéro de version automatiquement augmentée lors d'une nouvelle version de Firefox. Je ne sais pas exactement ce qui conditionne cette montée de version: JS only, utilisation de Jetpack, autres?
[^] # Re: Sympa
Posté par djano . En réponse à la dépêche Actionaz, un logiciel d'automatisation libre. Évalué à 3.
Pour automatiser le parcours d'un site web depuis un navigateur, je te conseille d'utiliser Selenium RC (Remote Control) ou bien WebDriver (inclus dans Selenium depuis la version 2).
Tu disposes en plus de Selenium IDE, une extension Firefox pour faire du capture / replay qui est très utile avec Selenim RC, un peu moins avec WebDriver.
[^] # Re: Pourquoi un tel désintérêt pour X ?
Posté par djano . En réponse à la dépêche Pourquoi Wayland veut remplacer X. Évalué à 2.
Sauf si la base (le protocole X et son implémentation X.org) est la raison originelle du manque de main d’œuvre.
Pour faire court: X embarque une tripotée d'API qui ne sont quasiment plus utilisées aujourd'hui. Elles étaient très utilisées et adaptées lorsqu'X a été créé, mais ne correspondent plus aux usages actuels (OpenGL). Beaucoup de ces fonctionnalités ont été sorties de X (gestion des fontes directement dans GTK ou Qt, KMS, etc.). Le problème c’est que pour qu'un logiciel puisse clamer être un serveur X, il doit implémenter toutes ces fonctionnalités obsolètes. Donc, a un problème d'architecture mentionné plus haut, s'ajoute un problème de conception qui n'est plus en phase avec son temps.
Comme avec tout logiciel devenu historique (legacy), on peut soit ne pas toucher beaucoup a son cœur et lui rajouter des extensions (c'est ce que l'on a fait jusque la avec X), jusqu’à ce qu'on le remplace, car trop lourd, trop cher, on peut faire mieux, etc.
Je crois que nous en sommes arrivés a ce point.
[^] # Re: Mauvaise foi
Posté par djano . En réponse à la dépêche Pourquoi Wayland veut remplacer X. Évalué à 1.
Calme toi, il a écrit Wayland la ou il aurait du écrire Weston. Il a simplement confondu l'implémentation avec le protocole.
Il sera fouetté 42 fois pour expier ce péché.
[^] # Re: Please fill out this field
Posté par djano . En réponse à la dépêche Appel pour le web ouvert !. Évalué à 2.
Euh, je suis moyennement d'accord. Comme il le dit bien:
Appelez ça gagner de la part de marché, appelez ça lock-in, mais oui ils ont une responsabilité la dedans. Laisser cette porte ouverte, a laissé certains développeurs peu soucieux ou ignorant des standards du web s'engouffrer dedans sans se poser aucune question.
Je comprends les besoins des navigateurs de se différencier et de proposer des innovations, mais je regrette qu'ils ne jouent pas le jeu des standards en premier. Lâcher une implémentation non spécifiée dans a la nature tout en faisant de la communication sur ces nouvelles fonctionnalités super-cool sans communiquer les habituels garde-fous (EXPÉRIMENTAL, etc.) montre une responsabilité.
Mozilla est bien plus vertueux lorsqu'ils publient publiquement des specs pour les nouvelles fonctionnalités, lorsqu'il les poussent dans les comités du W3C (ou du WHATWG précédemment) et ainsi de suite. Si tous les éditeurs faisaient la même chose, on n'en serait pas la.
Bref, je refuse de dire que le problème est uniquement du cote des développeurs web. C'est trop facile de dire ça.
[^] # Re: Please fill out this field
Posté par djano . En réponse à la dépêche Appel pour le web ouvert !. Évalué à 2.
Ce n'est pas parce que la situation actuelle est mauvaise que l'on doit la laisser se pourrir encore plus.
Si a partir d'aujourd'hui, toute nouvelle fonctionnalité est "protégée" d'une libre utilisation dans la nature comme Manuel Vonthron et Daniel Glazman le proposent, alors on va s'épargner le besoin de refaire une telle campagne de comm' dans le futur.
Reste a convaincre tous les éditeurs de navigateurs. Ce ne sera pas une mince affaire. Mais chat échaudé craint l'eau froide? S'ils n'aiment pas la situation actuelle, alors ils vont faire quelque chose pour 1) qu'elle ne se reproduise jamais, 2) qu'elle se résorbe petit a petit.
[^] # Re: Please fill out this field
Posté par djano . En réponse à la dépêche Appel pour le web ouvert !. Évalué à 2.
Ce n'est pas parce que les éditeurs font partie du W3C qu'ils soumettent tous leurs travaux au W3C, loin de la. Tu te heurte a la main droite qui ignore ce que fait la main gauche.
Tu as raison: les éditeurs font tout pour que leurs travaux soit utilisables, mais ils ne font pas tout pour que ce soit standardisé, loin de la.
Maintenant, je ne comprend pas ta défense de certains développeurs web qui font des sites webkit-only tout comme l'on avait des sites IE-only. Ce ne sont quand même pas les éditeurs de navigateurs qui ont forcé les développeurs a faire ça?
Alors je maintiens que le problème est double, et c'est exactement ce que Daniel Glazman dit aussi (respire un coup et relis ce qu'il a écrit). L'appel du W3C CSS Working Group demande a TOUT LE MONDE de faire un effort pour stopper cette situation: les éditeurs de navigateurs, les développeurs web et les utilisateurs de sites web.
[^] # Re: Please fill out this field
Posté par djano . En réponse à la dépêche Appel pour le web ouvert !. Évalué à 2.
Le problème est double:
Le mécanisme des extensions spécifiques au navigateur ont été créées pour permettre de tester les propositions de fonctionnalités faites au W3C CSS Working Group. Le problème c'est que ces propriétés sont accessibles dans les versions stables des navigateurs sans rien faire de spécial. Daniel Glazman a déjà dit que c’était un problème et que ce serait bien mieux si ces propriétés n'étaient accessibles que lorsque l'on active une configuration spéciale.
Les développeurs web se sont emparés de ces possibilités et ont commencé a créer des sites webs avec elles. Malheureusement ce qu'ils n'ont pas compris, c'est que ces fonctionnalités sont EXPÉRIMENTALES, parfois propriétaires car non soumises au W3C, parfois refusées par le W3C, parfois sous spécifiées, souvent pleines de bugs, …. Bref, autant je comprends leurs besoins, autant ils ont joué avec le feu surtout lorsque certains n'utilisaient que les extensions spécifiques a webkit.
Daniel Glazman fait parti du camp des éditeurs de navigateurs puisqu'il travaille énormément sur et autour de gecko.
Bref, le W3C CSS Working Group demande:
aux éditeurs de fournir les specs des extensions au W3C.
aux développeurs web de faire des sites web qui marchent avec tous les navigateurs (le plus possibles en tout cas) et pas seulement webkit, en utilisant les préfixes des autres navigateurs et les propriétés non préfixées lorsque cela est possible.
aux développeurs web d'arrêter de faire des sites web qui refoulent toute personne n'utilisant pas IE/Firefox/webkit.
aux utilisateurs de site web de se plaindre aux sites webs qui ne fonctionnent qu'avec un navigateur et de ne pas recommander de tels sites.
[^] # Re: à ce point là ?
Posté par djano . En réponse au journal Linux Magazine 146 - suicide ou rachat par google ? . Évalué à 2.
Désolé de te contredire, mais c'est malheureusement en train de changer :(
Orange s'autorise à examiner la navigation de ses abonnés à des fins publicitaires
Voila le nouveau business des opérateurs internet
Tu payes et encore derrière on t'exploite et te réexploite.
C'est du super foutage de gueule.
Si au moins c’était gratuit on saurait pourquoi ils font ça.
[^] # Re: Android, libre, pas libre ?
Posté par djano . En réponse à la dépêche Android et son monde. Évalué à 2.
Il me semblait avoir lu que les applis Google (Maps, Navigation, Gmail, etc.) ne sont pas libres. Mais ce n'est qu'un vague souvenir et ça reste à vérifier.
[^] # Re: Pour compléter...
Posté par djano . En réponse à la dépêche État d'insécurité chez PHP. Évalué à 2.
Des CMS développés en PHP? (Joomla, Drupal, etc.) :)
[^] # Re: Pour compléter...
Posté par djano . En réponse à la dépêche État d'insécurité chez PHP. Évalué à 2.
Est ce que Gradle correspond mieux a Scala? J'ai lu du bien de cet outil de build pour les langages de le JVM autres que Java. Gradle est un mélange entre Maven et Ant. Il te propose des conventions précises pour Java (tout comme Maven), tout en étant beaucoup plus facilement configurable et il est plus facile d'écrire des taches custom dans les fichiers de build.
Par exemple, tout besoin non conventionnel avec Maven va nécessiter l’écriture d'un plugin Maven (Bah!), il est difficile de changer le comportement par défaut, XML c'est sympa un moment mais ça devient quand même lourd au bout d'un moment.
Gradle c'est:
* la possibilité de scripter son build en Groovy dans le fichier de build,
* la possibilité de changer le comportement par défaut de certaines taches,
* des notations compactes pour décrire les dépendances.
* un outil de build pensé pour construire des projets codé en multi langages.
Malheureusement je ne l'ai pas encore essayé, et je suis sur que le revers de la médaille est que les fichiers de builds peuvent vite devenir illisible si un goret est passé par la. Alors qu'avec Maven, le fichier XML reste a peu près potable en tout circonstances (enfin, pour du XML quoi).
Bref, je conseille de jeter un œil sur Gradle aui a l'air très intéressant.
[^] # Re: Pour compléter...
Posté par djano . En réponse à la dépêche État d'insécurité chez PHP. Évalué à 3.
Je suis tout a fait d'accord.
La suggestion d'un return unique par méthode est bien pour des langages comme le C++ qui vont générer une tétra chiée d'appels aux destructeurs pour chaque return (quoique, j’espère que les compilateurs ont amélioré ça de nos jours?). Par contre, pour des langages comme Java, C#, Python, Perl, PHP, etc. ça ne sert strictement a rien et ça nuit a la lisibilité du code.
[^] # Re: Présentation pas si superflue
Posté par djano . En réponse à la dépêche Sonar 2.13 est disponible. Évalué à 2.
Bof pas vraiment dans mon souvenir pas si vieux.
En même temps, je ne rappelle pas avoir eu de cours expliquant bien les tests unitaires avec TP, sinon, je peux te dire que j'aurais perdu moins de temps pendant mes études. Pareil pour l'utilisation du logging au lieu des bons vieux system out dans du code multithreadé, bref, on apprend beaucoup de théorie, mais de tous petits ateliers de génie logiciel (UML ne compte pas) avec les bonnes pratiques ne ferait pas de mal du tout.
[^] # Re: JaCoCo, non ?
Posté par djano . En réponse à la dépêche Sonar 2.13 est disponible. Évalué à 2.
Non c'est pas la suite.
JaCoCo a été démarré par le gars qui maintient le plugin Eclipse d'Emma appelé EclEmma. Il avait plein de rapports de bug pour Emma, mais il n'y avait aucun mainteneur et pas de tests unitaires non plus. Alors il a décidé de réécrire une librairie pour vérifier la couverture de code.
Voila comment JaCoCo est né, c'est une base de code complètement différente, donc ce n'est pas la suite d'Emma, mais un remplacement total.
[^] # Re: Part de CA générée par Crème CRM
Posté par djano . En réponse à la dépêche Logiciel libre et création d'entreprise : entretien avec 2 des créateurs de Hybird . Évalué à 2.
Bah c'est un peu comme la sécurité. La plupart s'en foutent royalement jusqu’à ce que cela crée des problèmes. Et la il faut tout corriger tout de suite. Mais il n'y a plus personne pour payer, alors que pour ajouter des fonctionnalités inutiles, la il y a plus de monde.
[^] # Re: Webp semble incomplet...
Posté par djano . En réponse au journal WebP, le format d'images ultime. Évalué à 2.
Une image MNG ne peut pas être lue par un navigateur supportant les images PNG. Du coup, il n'y a pas de possibilité d'adoption progressive de ce format sur le web. Ce défaut ajouté a la taille du code requise pour gérer le MNG (commentaire ci-dessus) a poussé Mozilla a inventer l'APNG qui n'a pas rencontré beaucoup plus de succès.
[^] # Re: Sauver la face ?
Posté par djano . En réponse à la dépêche La mort de Knol est annoncée. Évalué à 2.
Ah! Si toutes les entreprises étaient de ton avis, ce serait le rêve...
[^] # Re: "Comment utiliser efficacement Git ?"
Posté par djano . En réponse à la dépêche Jeudi du Libre de décembre à Lyon : Git, ou comment donner l’impression qu’on est un supercodeur ?. Évalué à 2.
Tu commites 100+ fichiers d'un coup toi?
Je plains le pauvre gars qui doit faire ta revue de code.
Les commits réguliers et individuels sont le mieux pour pouvoir travailler vite et faire souvent du refactoring.
1 commit = 1 intention
[^] # Re: L'api, elle est cassé
Posté par djano . En réponse à la dépêche Sortie de Seeks en version stable 0.4. Évalué à 2.
Facile a corriger:
"API is broken down into plugin dependent fragments."
Et voila!
[^] # Re: Encore un langage de "haut"-niveau interprété par le navigateur?!
Posté par djano . En réponse à la dépêche Dart va‐t‐il remplacer JavaScript comme langage dans les navigateurs ?. Évalué à 2.
Ah bon? Bah, c’était la préhistoire :)
Je suis arrivé a la programmation lorsque Java 1.4 était la.
Mais certains projets Apache on la fâcheuse manie d'absolument vouloir compiler leur code avec Java 1.2 ou mois. Y a-t-il vraiment encore des gens qui compilent du code avec Java 1.2 ou moins et qui ont besoin que leur libs soient compilées avec cette même version?
[^] # Re: mouais
Posté par djano . En réponse à la dépêche Découvrir Xtend, un langage extension de Java. Évalué à 2.
Non, ce n'est pas la raison. La raison est qu'un accès direct aux champs n'est pas polymorphique (c'est même statique comme le précise Buf) et bloque donc toute réutilisation de ce code avec de la programmation objet, ce qui peut être très gênant et conduire a des copier coller (quelle monstruosité!).