De tout, de rien, des bookmarks, du bla bla #29

Posté par CrEv (site web personnel) le 17 juillet 2013 à 09:33. Édité par tuiu pol, palm123, claudex, Nils Ratusznik, Benoît Sibaud et Pierre Jarillon. Modéré par Nils Ratusznik. Licence CC By‑SA.

Étiquettes :

juil.

2013

Et oui, après une (beaucoup trop) longue absence, re-voici un numéro de « De tout, de rien, des bookmarks, du bla bla ». Il était temps. Vous trouverez donc, comme précédemment, un peu de tout, beaucoup de choses qui concerne le développement mais pas que, le tout fonction de ce qui m'a intéressé ces derniers temps. N'y cherchez pas spécialement de l'objectivité, le but est de vous faire partager ce qui m'a fait vibrer, de vous donner envie ou juste de vous divertir (ben quoi, on peut se divertir avec de l'info non ?).

Comme toujours, vous trouverez une liste des liens présentés en fin d’article, pour que les plus rapides puissent cliquer directement sans lire le bla‐bla qui traîne autour.

Avant-propos

Désolé si ce numéro est un peu moins passionnant que les autres, d'autant plus que certains liens commencent à dater. Néanmoins j'ai essayé de ne garder que le meilleur ;-)

Il faut dire que j'ai été un peu moins passionné par le monde du web ces derniers temps. Ok, on trouve beaucoup de choses sur AngularJS par exemple, sur du CSS, sur des bibliothèques JS, etc. Mais je dois dire que j'ai un peu l'impression que ça tourne en rond. Certes c'est toujours plus mieux, certes il y a des nouveautés. Mais il y a aussi beaucoup de réinventage de roue, de NIH. Depuis que j'ai commencé à vraiment coder sur le web, il y a une petite dizaine d'année, j'ai l'impression que ça n'a pas beaucoup évolué par certains côtés. On se retrouve à, encore aujourd'hui, refaire une énième bibliothèque de composants html/js pour, par exemple, styliser des listes déroulantes. Le style à changé, c'est vrai. On est d'ailleurs passé par pas mal de choses, des biens lourdes pendant un temps, et on s'oriente vers du minimalisme, avec des couleurs bien utilisées et un accent sur la typographie. Les outils ont changé aussi, on voit maintenant fleurir le code utilisant des pré-processeurs malgré l'aversion de certains (less et sass, mais aussi stylus pour le css, coffeescript pour le javascript par exemple). On voit aussi les systèmes de build, de gestion de dépendance (bower et requirejs).

Tout ça c'est bien, ça va dans le sens d'une industrialisation dont le web (et plus généralement malheureusement le développement) manque cruellement. Mais se retourner et voir qu'on fait par certains côtés toujours la même chose depuis 10 ans, c'est tout de même un peu triste, non ?

OK, je suis peut-être un peu amer, mais n'oubliez pas, ceci n'a pas pour vocation d'être objectif ;-)

Allez, ne vous en faites pas, il y a tout de même plein de choses sympa à voir dans la suite. Et même concernant le web, comme quoi !

Un peu de contenu

Développement

Et justement, pourquoi ne pas commencer par du web ? Voici donc une présentation concernant les « Web components, l'avenir des développeurs web ». Pfiou, il était temps qu'on essaie un peu d'avancer sur ce point, histoire de standardiser tout cela.

Si vous faites du web, je pense que vous avez forcément utilisé jQuery. Non ? Bien ! (ben quoi, moi je n'utilise pas jQuery pour faire du web, j'aime pas vraiment jQuery) Quoi qu'il en soit, vous serez par contre probablement intéressés par cette version documentée de jQuery 1.6.2. Un sacré travail pour annoter tout ce javascript, mais de quoi comprendre plus en détail le fonctionnement de cette bibliothèque si utilisée. La version annotée a été créée en utilisant docco dont je vous avais déjà parlé.

Voici aussi une présentation assez sympa sur le javascript et le mode strict : « Web directions ». À regarder, elle est plutôt cool et le message est vraiment intéressant.

Et une autre présentation qui cette fois nous apprend comment devenir un expert en javascript alors qu'on est un développeur intermédiaire : « Javascrip Masterclass »

Histoire de jouer un peu avec le javascript, voici comment créer un compilateur Lisp vers Javascript.

Puisque j'en parlais en introduction, voici une comparaison entre less et sass.

Et pour rester sur du design web, voici une très bonne explication sur comment faire des balles en CSS. Didactique, bien illustré, c'est plutôt un bon article. D'ailleurs vous pouvez suivre les liens pour voir les autres, c'est pas mal non plus.

Sortons un peu du javascript… pour aller vers du Java ! Je n'ai jamais essayé (et si certains l'ont fait ça m'intéresse) mais voici takipi. Il s'agit d'un système de débugage à distance pour des applications Java. Ça a l'air plutôt cool et pratique, l'interface semble plutôt pas mal aussi.

Comme à chaque fois qu'il sort un article, c'est une véritable mine d'or. Honnêtement je ne l'ai pas lu en entier, il faut dire que c'est d'un sacré niveau. Allez, je vais vous faire deviner le lien, c'est facile. Il s'agit d'un Français qui a sa boite au Canada. Il a juste un niveau plutôt impressionnant, surtout en ce qui concerne le bas niveau, le c, le c++, et les jeux. Et John Carmack a retweeté sa dernière revue de code. Alors, trouvé ? Et oui, il s'agit de Fabien Sanglard qui a réalisé une revue de code de Doom 3 BFG.

Et vu que je sais que vous en redemandez encore, voici une autre revue de code concernant cette fois Prince of Persia. Que ce jeu a pu bercer mon enfance ! Je me souviens encore, vu les dates ça devait être en 1990, je descendais dans le bureau de mon père pour qu'il allume son ordinateur (un 286) et pouvoir jouer quelques minutes à Prince of Persia. Le bruit des lames, sortant du buzzer de la machine, résonne encore dans ma tête ! Franchement c'est un des meilleurs souvenirs de jeux vidéo que je peux avoir. Peut-être parce que c'était probablement l'un des (le ?) premiers auxquels j'ai joué. J'en verserais presque une petite larme ;-)

Franchement, certains s'ennuient vraiment. Mais heureusement pour nous car cela donne des choses genre « The Shortest Crashing C Program ».

(J'espère que ce lien n'est pas déjà passé sur linuxfr) Si vous vous intéressez aux maths dans l'informatique ou aux jeux vidéos, voici un (long) article passionnant sur les grilles hexagonales. Et il faut en plus dire que cet article est très bien illustré, avec même des animations pour bien comprendre comment cela fonctionne. Vraiment à lire !

Je suis tombé (ouille) sur cet article vraiment intéressant, sur une façon de (bien) faire de la programmation par objet : Object Calisthenics. En gros il s'agit de neuf règles assez simples, mais qui une fois mises en œuvre rendent le code plutôt sympa. A rapprocher de SOLID aussi. Voici les règles, pour les détails allez lire le lien :

Un seul niveau d'indentation par méthode
N'utilisez pas le mot clé else
Emballez (wrap) toutes les primitives et chaînes de caractères
Les collections dans leurs propres classes
Un . par ligne
N'abrégez pas
Gardez toutes les entités petites
Pas de classe avec plus de deux variables d'instance
Pas de méthodes de Getter/Setter

Qu'en pensez-vous de ces règles ? Si certaines me semblent vraiment bien, la 8 me semble plutôt stricte et complexe à mettre en œuvre, surtout si on la rapproche de la 5.

Histoire de terminer cette partie, avez-vous déjà lu ce livre : « Real-time Systems and Programming Languages: Ada, Real-Time Java and C/Real-Time POSIX » ? C'est probablement le prochain que je lirai après « Programming in Ada 2005 ».

Misc

« ABC: Always Be Coding » : Article très intéressant sur les développeurs, savoir si on est un bon candidat, et quelques astuces pour devenir encore meilleur. C'est très rapide à lire, et même si ça enfonce quelques portes ouvertes c'est plutôt sympa.

D'ailleurs, tiré de ce même lien, voici un pense-bête sur la complexité des algorithmes. À garder dans un coin ça peut toujours servir.

Un problème très souvent rencontré dans l'ingénierie logicielle concerne l'estimation du temps de développement. Il y a plein de raisons à cela, de toutes natures. Et il y a aussi beaucoup de courants différents, par exemple ceux qui veulent estimer (prédire ?) très précisément les développements, en étant très précis (inférieur à la demi-journée). Il y a aussi un courant des méthodes agiles, plutôt orienté estimation (genre 2 points ça veut dire entre 1 et 3 jours idéaux). Et il y a encore au delà de tout cela, un courant plutôt orienté pas d'estimations. Il m'est arrivé de vouloir faire du pas d'estimations mais cela nécessite pas mal de boulot mine de rien, entre autre bien découper les tâches par exemple. M'enfin ça c'est si on veut tout de même essayer de suivre un peu l'avancement, sinon on arrive de nouveau à la rache. Bon allez, tout ça pour introduire ce lien plutôt intéressant au sujet des estimations, entre autre en réponse au pas d'estimation : « Estimates in Software Development. New Frontiers. ».

Et pour continuer sur le thème des estimations, un message assez intéressant : « Don't get demoralized by bad estimates! ».

Les commentaires sont-ils nécessaires ? Comment ça un air de déjà vu ? Non, cette fois-ci il s'agit des commentaires sur les blogs. Est-ce vraiment nécessaire ? Est-ce indispensable ? Que penser d'un blog qui n'en aurait pas ? Et je ne parle pas de quelqu'un qui les désactive, mais vraiment aucun commentaire. Pour ma part je comprends tout à fait qu'il n'y ait pas de commentaires. D'ailleurs je n'en ai pas sur mon blog. Pourquoi ? Initialement une raison technique (blog statique et auto hébergement), finalement est-ce si important que cela ? Des réactions j'en ai tout de même, que ce soit sur tweeter, google+, par mail, par pull request aussi. Certes c'est plus dispersé, et alors ? Bon c'est sur que venir taper sur les commentaires tout en publiant sur linuxfr c'est tout de même assez drôle, surtout à quel point, souvent, le contenu intéressant et particulier de linuxfr est justement dans les commentaires. Mais là c'est différent, il y a réellement une communauté. Il ne s'agit plus de commenter sur un blog perso. Un jour il y aura probablement des commentaires sur mon blog, en attendant je vous renvoie donc vers cet article traitant de la nécessité des commentaires.

Un mythe s'effondre ! Vous connaissez tous Valve je pense. Peut-être certains connaissent le système de management de Valve (dont j'ai déjà parlé dans de précédents numéros) et qui me semblait intéressant voire motivant. Mais voici que quelqu'un s'élève contre ce système qui est plutôt qualifié de management masqué. Je vous laisse le lire ici : Valve's 'perfect hiring' hierarchy has 'hidden management' clique like high school. Mais finalement, existe-t-il des managements qui soient vraiment bien et sans intérêts masqués ?

Graphisme, design & co

Ok c'est pas vraiment du graphisme, ni du design, mais on va mettre ça dans le co. J'ai toujours une fascination étrange à propos des lieux abandonnés. Surtout ceux désertés en laissant tout sur place, rapidement. Oui je sais, c'est particulier. Mais si ça vous intéresse ou que vous voulez juste voir quelques belles photos, voici « 50 lieux abandonnés et villes fantômes incroyables ».

Voici deux liens vers des polices de caractères à utiliser, par exemple sur le web. L'un concernant des polices de type Stencil, l'autre des polices de type Cursive.

Comment réaliser une bonne interface utilisateur (sur le web) ? Cet article imagé tente de proposer quelques pistes, essentiellement autour de la cohérence : goodui.org

Liste des liens présentés

Aller plus loin

Tag « Veille technologique » sur LinuxFR.org (381 clics)
Épisode précédent (74 clics)

# quelques points

Posté par Nicolas Boulay (site web personnel) le 17 juillet 2013 à 10:16. Évalué à 10. Dernière modification le 17 juillet 2013 à 10:21.

« ABC: Always Be Coding » est à rapprocher d'un autre article sur le même sujet, mais qui donne des conseils à ceux qui pose des questions.

L'auteur de cette article propose de savoir écrire les yeux fermé des algo comme A*, des parcours de graph et autre algo de trie. La facilité de faire cela serait un bon moyen d'être embauché.

Mais quel informaticien écrit en moyenne par mois, de tel algo ? Personne ou presque. Un codeur passe son temps à architecturer du code, prévoir plus ou moins l'avenir, revoir les besoins du "clients", debuguer. Mais certain aucun temps à faire ce genre d'exercice.

Concernant les structures de données, il ne sert à rien d'avoir des collections complexe pour des tailles inférieurs à 100. Le O(1) cache souvent un cout fixe énorme, il ne faut pas jeter trop vite les bon vieux tableaux ou liste chainé.

"La première sécurité est la liberté"
- [^] # Re: quelques points
  
  Posté par ckyl le 17 juillet 2013 à 11:16. Évalué à 6.
  
  L'auteur de cette article propose de savoir écrire les yeux fermé des algo comme A*, des parcours de graph et autre algo de trie. La facilité de faire cela serait un bon moyen d'être embauché.
  
  En France non. Autrement cela me semble assez vrai vu les différents entretiens que j'ai pu faire.
  
  En fait le truc c'est d'être capable de démarrer rapidement à froid et de garder la gymnastique que tu pouvais avoir à la fac. C'est certe un exercice très artificiel, auquel je suis mauvais, mais ca paie aussi dans la vraie vie. Dès que tu as besoin de faire un peu plus que manipuler l'API standard (mauvaise performance de l'implémentation par défaut, overhead mémoire, faire juste job qu'on te demande etc.)
  
  Mais quel informaticien écrit en moyenne par mois, de tel algo ?
  
  Écrire du code avec ce genre de gymnastique, cela m'arrive fréquemment alors que je dev majoritairement en Java.
  
  Personne ou presque. Un codeur passe son temps à architecturer du code, prévoir plus ou moins l'avenir, revoir les besoins du "clients", debuguer. Mais certain aucun temps à faire ce genre d'exercice.
  
  C'est vrai. Le reste c'est extra bonus pour ceux qui font du code qui doit répondre à un besoin précis et pour lequel optimiser quelques trucs après mesure à un sens par rapport au coût de dev (hello big data, langage à la con où le boxing des types primitifs est hors de prix ou bibliothèques largement réutilisées).
  
  Regarde un peu ce qui est open-sourcé par Google, Twitter, Linked-in et tous les autres. C'est bourré de choses de ce genre par ce qu'on en à besoin et que les runtimes standards ne fournissent pas ce qu'il faut.
  
  Concernant les structures de données, il ne sert à rien d'avoir des collections complexe pour des tailles inférieurs à 100. Le O(1) cache souvent un cout fixe énorme, il ne faut pas jeter trop vite les bon vieux tableaux ou liste chainé.
  
  Déjà des gens qui comprennent le Big O ca court pas les rues. Si en plus tu essaies de leurs faire comprendre le k ou simplement les choix d'implémentation par rapport à comment fonctionne une machine, ca va faire beaucoup. Ils pourraient du coût être amené à écrire le genre de code dont on parlait ou comprendre qu'en réécrivant 15 lignes ils diminuent par 10 la conso mémoire ;)
- [^] # Re: quelques points
  
  Posté par giant_teapot (site web personnel) le 17 juillet 2013 à 11:57. Évalué à 3.
  
  L'auteur de cette article propose de savoir écrire les yeux fermé des algo comme A*, des parcours de graph et autre algo de trie. La facilité de faire cela serait un bon moyen d'être embauché.
  
  Propos intéressant et qui me rappelle un étido paru sur TechCrunch il y a quelque temps sur l'utilisation des exercices d'algo lors des entretiens, au détriment de choses un peu plus "concrètes" comme la façon de mener à bien un projet (article ici).
  
  Pour ma part, je suis partagé. Je continue de penser que l'algo est quelque chose de primordial quel que soit le rôle dans une équipe de dev. Chacun doit pouvoir être en mesure de remettre en question les choix faits, mettre en perspective l'apport en complexité d'une structure de données et son usage ou d'un algorithme.
  
  Par contre j'admets volontiers que le niveau en algo ne fait pas tout et peut même avoir des effets pervers. Je pense principalement à la "réinvention de la roue". Quasiment toutes les structures de données sont disponible d'une façon ou d'une autre pour un langage donné, et souvent optimisées par rapport aux particularités dudit langage.
  
  Au final, l'important est peut-être d'avoir une bonne vision d'ensemble des enjeux de l'algorithmique (le Big O en tête) et ainsi que des limites des outils les plus courants (algos et structures de données).
  - [^] # Re: quelques points
    
    Posté par ckyl le 17 juillet 2013 à 12:42. Évalué à 9. Dernière modification le 17 juillet 2013 à 12:43.
    Quasiment toutes les structures de données sont disponible d'une façon ou d'une autre pour un langage donné, et souvent optimisées par rapport aux particularités dudit langage.
    
    Il faut aussi faire attention à ca. Évidement on commence par utiliser les trucs standards quand c'est possible pour aller vite et identifier ce qui va poser problème ou non (approche type balle tracante).
    
    Maintenant dès que tu t'intéresse un peu à ce que tu fais ou que tu es dans un contexte un peu différent de "Je pisse du code pour la webapp lambda" tu tombes rapidement sur des trous ou des choses qui méritent un peu d'attention.
    
    Exemple débile d'hier: trier une liste d'entiers selon un comparateur adhoc en Java. Bha ca n'existe pas. Du coup j'ai trois solutions:
    1. Je trouve quelque part une dépendance qui fait ca. Mes clients vont être content et moi aussi, un truc de plus.
    2. Je converti mon int[] en Integer[] ou en ArrayList et ma consommation mémoire fait mini x3 sans parler de l'impact sur les perfs.
    3. Je comprends les caractéristiques de l'objet que je manipule. Je connais les outils algorithmique à ma disposition. Je peux écrire en une à deux heure le code du tri adapté à mon besoin. C'est dommage que ce ne soit pas built-in mais ces deux heures vont me faire des heures à l'exécution et gagner des Mo de RAM pour aucun autre coût que ces deux heures.
    En pratique tu tombes très souvent sur des cas comme ca. En Java 6 String.split passe par des regex même si tu utilises un bête char comme délimiteur. Ca me coute 20% de mon temps d'exécution ? Je prends 1h pour le réécrire. L'UX n'est pas contente de l'highlighting de mot faire par Solr ? Je désactive et je le recode avec d'horribles algo sur les chaînes de caractères etc.
    
    On utilise les outils qui existent quand c'est possible, mais on n'hésite pas à mettre les mains dans le cambouis quand c'est justifié. C'est une histoire d'équilibre, comprendre ce qu'on manipule et essayer de faire le choix le plus judicieux à court et long terme.
    - [^] # Re: quelques points
      
      Posté par barmic le 17 juillet 2013 à 13:23. Évalué à 5.
      C'est ce que je pensais il y a 2 ans (en sorti d'étude). Maintenant, je pense sincèrement que l'algo n'est pas aussi primordial que ça. C'est quelque chose qui se retrouve que tu mette 1h de plus ou moins qu'un autre là dessus n'est pas très important (AMHA). Ce qui pour moi est réellement primordial, c'est de savoir tester (unitaire, d'intégration et bench), ça permet entre autre :
      
      d'avoir du code de meilleur qualité
      
      plus fiable dans le temps et plus maintenable
      
      de déterminer les endroits qui posent problème comme tu l'indique et d'évaluer l'efficacité relative de ta solution sur la précédente
      
      Aujourd'hui il me semble bien plus important d'avoir une équipe qui sait faire et gérer les tests que de très en algo qui seront un peu rirac sur les tests.
      
      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
      - [^] # Re: quelques points
        
        Posté par ckyl le 17 juillet 2013 à 13:57. Évalué à 4.
        
        Je ne vais pas te contredire c'est juste la base de la base. Autrement tu n'es pas développeur mais membre de la compagnie créole ;)
        
        Je n'ai pas dit non plus, que c'était un bon critère de recrutement. Je n'en ai pas encore découvert.
        
        Par contre la vision uniquement plomberie du job "yatoudanlélib" va finir par faire vraiment des ravages. Y'a un moment tu as besoin d'avoir des bases pour comprendre et être capable de proposer, estimer et implémenter différentes solutions. Ce n'est pas une histoire de prendre une heure de plus. C'est d'avoir un pied dans la réalité, d'être capable de proposer des solutions aux meilleur coût, de connaitre les ordres de grandeur, de connaitre que des choses existes, de faire des choses qui marchent bien.
        
        Force toi à recoder ce genre de chose, à explorer des katas ou des algos différent de ceux bateaux qu'on t'a appris et tu verras que ca risque de te faire le plus grand bien à moyen terme.
        
        Le monde bouge, les structures de données aussi.
        
        C'est quelque chose qui se retrouve que tu mette 1h de plus ou moins qu'un autre là dessus n'est pas très important
        
        Franchement y'a un moment où on ne parle pas d'une heure. Mais simplement de la capacité à le faire, de savoir que les choses existes et d'être capable de transformer une publication en dans code pour ton besoin.
        
        [^] # Re: quelques points
        
        Posté par Nicolas Boulay (site web personnel) le 17 juillet 2013 à 14:16. Évalué à 7.
        
        Franchement, dans le cycle de dev, l'optimisation en temps arrive à la toute fin, et en général, on a pas le temps, sauf si cela devient une "feature".
        
        L'optimisation a aussi un coup de maintenance (code peu lisible, plus gros, etc…). Et souvent, cela ne vaut pas le cout d'optimiser. Le seul moyen de savoir si cela vaut le cout, c'est de faire des mesures (donc à la fin d'un dev).
        
        "La première sécurité est la liberté"
        
        [^] # Re: quelques points
        
        Posté par ckyl le 17 juillet 2013 à 14:26. Évalué à 5.
        
        Ca dépend de ce sur quoi tu bosses, comment et quels sont tes objectifs…
        
        Y'a un moment faut arrêter les conneries, si t'es capable de livrer un produit qui consomme 4x moins de mémoire simplement par ce que tu as branché ton cerveau 5 minutes tu le fais de base. Idem en perf. Idem pour utiliser des structures de données/algorithme adaptées au problème plutôt que tes 3 structures de base.
        
        Dire que tout existe tout fait pour tout les usages, c'est soit de la connerie pure soit que tu ne fais rien d'intéressant.
        
        [^] # Re: quelques points
        
        Posté par reno le 17 juillet 2013 à 15:04. Évalué à 3.
        
        si t'es capable de livrer un produit qui consomme 4x moins de mémoire simplement par ce que tu as branché ton cerveau 5 minutes tu le fais de base.
        
        Non!! Tu viens de contredire allègrement le principe de mesurer avant d'optimiser.
        Encore récemment j'ai été surpris quand j'ai voulu optimiser un script: la fonction 'couteuse' n'était pas là ou je l'attendais.
        
        [^] # Re: quelques points
        
        Posté par GaMa (site web personnel) le 17 juillet 2013 à 15:30. Évalué à 3.
        
        Si je suis d'accord avec le principe de "mesurer avant d'optimiser", il ne faut pas le suivre bêtement au point de ne pas réfléchir sous prétexte qu'on verra plus tard.
        
        Ce principe s'applique très bien (et quasiment sans exception) lorsque tu es sur un projet «terminé». Si, à ce moment, tu changes une fonction parce que ton pif te dit que c'est là, effectivement, tu as tord.
        
        Par contre au moment où tu écris ton code, si tu ne te pose pas de question sur la structure de donnée à utiliser, tu va vite voir que pour optimiser derrière, ben t'en sera quasiment à tout réécrire par ta structure est pas adaptée, que c'est elle qui faut changer (et donc tous les algo qui vont avec).
        Alors qui si te pose la question des perfs en amont, tu choisie la bonne structure de donnée, la bonne organisation "globale" de ton code. (genre pas faire trois fois le même tri). Lorsque tu vas faire tes mesures, tu verras que les changements à faire seront probablement plus chirurgicales et tu t'éviteras de longue nuit de rush parce que "les perfs c'est à la fin quand tout marche qu'on y pense".
        
        Matthieu Gautier|irc:starmad
        
        [^] # Re: quelques points
        
        Posté par Nicolas Boulay (site web personnel) le 17 juillet 2013 à 15:38. Évalué à 5.
        
        Je confirme, il y a 2 moyens de gagner du temps :
        - avoir une bonne archi (ne pas faire 2 fois le même boulot couteux, éviter un parcours exponentiel.)
        - hacker (refaire les trucs à la main, …)
        
        Le 1er se fait en amont, avec des gains monstrueux à la clef (x1000). Le 2ième te fait gagner x10 maxi.
        
        En général, les optimisations prématurées ne font rien gagné du tout, et rajoutent des bugs. C'est plus difficile de faire marcher un truc le plus simplement du monde (== moins de code, moins de bug, plus petit,…), que de le faire aller plus vite ensuite.
        
        "La première sécurité est la liberté"
        
        [^] # Re: quelques points
        
        Posté par ckyl le 17 juillet 2013 à 15:57. Évalué à 5.
        
        Effectivement.
        
        Maintenant une empreinte mémoire ca se calcule à l'avance. Un algorithme ou une structure de donnée adapté ca se choisi selon le contexte. Les structures de données toutes faites c'est cool oui.
        
        Maintenant utiliser une TreeMap<Integer, Integer> vaut-il le coup de payer multiplier par 9 la consommation mémoire de mon appli ? Quand j'ai 100M d'éléments ?
        
        De même quand tu choisis d'implémenter le safe browsing dans un navigateur tu sais très bien que tu vas pas utiliser un set pour contenir les URL malicieuses mais que tu vas te coder un bloom filter.
        
        De même quand tu sais que ton code va traiter quelques dizaines de milliards d'entrées par jour tu n'attends pas la fin du dev pour mesurer ce que tu fais et lancer un profiler.
        
        Si tu n'as plus junior devant ton nom tu sais aussi commencer à estimer ce qui va coûter cher ou non et le mesurer corriger ASAP pour ne pas cumuler des choses non-rattrapables.
        
        Après oui, on mesure pour optimiser le code. Le faire à la fin, ca peut surtout vouloir dire le faire à la fin de la story… Pas 12 mois après quand on peut plus rien refactorer, qu'on a jamais eu de baseline de perf et que y'a plus de budget ni de temps. Si je livre une feature, elle doit tenir la charge pour laquelle elle est prévue et trouver le meilleur ratio coûts de prod/dev.
        
        Bref le dev c'est comprendre le métier et les contraintes et s'adapter. Des fois ca veut dire faire de la plomberie bête et méchante, des fois ca de réimplémenter des trucs ou utiliser des choses non conventionnelles ou peu diffusées par ce que ca à un sens d'un point de vue business. Et c'est beaucoup moins rare qu'on le croit.
        
        [^] # Re: quelques points
        
        Posté par Nicolas Boulay (site web personnel) le 17 juillet 2013 à 16:02. Évalué à 2.
        
        "Si tu n'as plus junior devant ton nom tu sais aussi commencer à estimer ce qui va coûter cher ou non et le mesurer corriger ASAP pour ne pas cumuler des choses non-rattrapables."
        
        En général, ceux qui disent ça, n'ont plus "junior" devant leur titre, mais par encore "senior" ou "expert".
        
        "La première sécurité est la liberté"
        
        [^] # Re: quelques points
        
        Posté par ckyl le 17 juillet 2013 à 16:17. Évalué à 4. Dernière modification le 17 juillet 2013 à 16:21.
        
        On peut aller loin avec des grandes phrases comme ca ;)
        
        Comme toujours c'est très différent en fonction de ton produit. Entre l'appli d'entreprise interconnectée à 1000 services utilisant 300 frameworks avec 5000 features ou tu ne vas rien pouvoir prévoir niveau perf du code avant la fin et du code du batch qui parse du fichier à gogo ou un service spécifique il y'a un monde.
        
        Quand ton produit est à taille humaine, on est tout à fait capable d'estimer "au pif" si telle ou telle solution est viable et de le POCé/testé en quelques minutes si on a besoin de chiffre.
        
        Tu le dis toi même d'une autre facon dans ton commentaire:
        
        Je confirme, il y a 2 moyens de gagner du temps :
        - avoir une bonne archi (ne pas faire 2 fois le même boulot couteux, éviter un parcours exponentiel.)
        
        Ta bonne archi elle vient d'où ? D'une conception qui tient compte de tes requirements et des coûts dev & runtime des différentes options. Tu réfléchis à ce dont tu as besoin puis tu regardes si y'a un truc qui y répond. Sinon tu te sors les doigts plutôt que mettre ca sous le tapis. On est pas d'accord ?
        
        [^] # Re: quelques points
        
        Posté par Nicolas Boulay (site web personnel) le 17 juillet 2013 à 17:00. Évalué à 4.
        
        Faire une architecture correct et simple, ou recoder une fonction qui existe déjà pour aller plus vite, ce n'est pas la même démarche. Pas du tout.
        
        Si tu recodes String.split, alors que tu n'utilises cette fonction uniquement pour lire une configuration à l'init, cela ne sert à rien. Par exemple.
        
        _"Quand ton produit est à taille humaine, on est tout à fait capable d'estimer "au pif" si telle ou telle solution est viable et de le POCé/testé en quelques minutes si on a besoin de chiffre." _
        
        Sauf pour le gros grain, mais une fois ton archi faite, en général les estimations aux doigts mouillés des "bottlenecks" de performance, sont en général fausses.
        
        "La première sécurité est la liberté"
        
        [^] # Re: quelques points
        
        Posté par ckyl le 17 juillet 2013 à 18:07. Évalué à 3.
        
        Si tu recodes String.split, alors que tu n'utilises cette fonction uniquement pour lire une configuration à l'init, cela ne sert à rien. Par exemple.
        
        Oui ca c'est enfoncer des portes ouverte ;)
        
        D'ailleurs il m'a fallu attendre près de 10 ans pour en avoir besoin.
        
        Sauf pour le gros grain, mais une fois ton archi faite, en général les estimations aux doigts mouillés des "bottlenecks" de performance, sont en général fausses.
        
        Personne n'a dit de faire de la micro-optimisation au doigt mouillé il me semble… Choisir une représentation mémoire, une structure de donnée ou un algorithme en fonction des besoins et non de ce que te files la lib standard (tant mieux si ca correspond) ce n'est pas ca en tout cas.
        
        Il me semble que les discussions se sont croisés.
        
        L'exemple était donné pour répondre à un commentaire qui disait pour caricaturer "y'a tout de dispo en plus rapide que tu ne peux l'écrire dans les libs, réfléchit pas trop et utilise". Ce a quoi je répondais que de mon expérience ce n'est pas vrai. Tu te retrouves fréquemment a réécrire ou implémenter toutes sortes de choses pour des raisons objectives. À aucun moment je n'ai évoqué l'idée de recoder un split au pif.
        
        Le coup de savoir estimer le coût de quelque chose, c'est ce que toi tu appelles "choisir l'archi". Je ne pense pas qu'on soit fondamentalement en désaccord.
        
        "Choisir l'archi" c'est par exemple implémenter un Hyperloglog++ par ce que tu as besoin de faire des dizaines de milliers d'estimations de cardinnalité d'ensemble de millions/milliards d'éléments. C'est ne pas utiliser une collection standard quand tu sais que ca te fait 4x en empreinte mémoire et que ca va te poser problème pour ces objets en particulier. Bref se focaliser sur ce qui est important pour répondre à un besoin donné.
        
        Après on profile et on gratte ce qu'il reste à gratter.
        
        [^] # Commentaire supprimé
        
        Posté par Anonyme le 18 juillet 2013 à 09:41. Évalué à 3.
        
        Ce commentaire a été supprimé par l’équipe de modération.
        
        [^] # Re: quelques points
        
        Posté par Guillaume Denry (site web personnel) le 18 juillet 2013 à 10:11. Évalué à 3.
        
        Mouais. C'est un peu à côté de la plaque, la citation de Linus (bien qu'excellente) concerne les gens qui cherchent la réponse la plus correcte (au sens mathématique) au détriment du temps.
        Alors qu'ici, il s'agît de déporter la phase d'optimisation ultérieurement, si besoin.
        Je sais bien que de calculer une valeur approximée suffisamment significative n'est pas forcément toujours plus simple que de calculer une valeur exacte, mais pour moi, le message de Linus s'adresse avant tout à ceux qui font un excès de zèle dans l'exactitude.
        
        [^] # Commentaire supprimé
        
        Posté par Anonyme le 18 juillet 2013 à 10:31. Évalué à 2. Dernière modification le 18 juillet 2013 à 10:31.
        
        Ce commentaire a été supprimé par l’équipe de modération.
        
        [^] # Re: quelques points
        
        Posté par Guillaume Denry (site web personnel) le 18 juillet 2013 à 10:39. Évalué à 4.
        
        Cela s'appelle un exemple, mais sa citation est générale.
        
        Oui mais justement, l'esprit générale de cette citation ne me semble pas trop en phase avec la problématique qui est de développer un truc qui répond aux besoins mais avec un effort modéré porté sur l'optimisation en temps. En général, dans ce genre de cas, on sacrifie rarement l'exactitude des résultats pour l'optimisation, cette dernière vient en plus. Sacrifier l'exactitude des résultats est très souvent lié à des calculs mathématiques.
        
        [^] # Re: quelques points
        
        Posté par ckyl le 18 juillet 2013 à 11:27. Évalué à 8.
        
        Oui enfin je vois toujours pas pourquoi on parle d'optimisation en fait…
        
        Construire un truc qui marche vite c'est à la conception, à la réalisation puis à l'optimisation. Tes choix de design/structures/algo tu les fais pas après une fois que tu te rends compte benoitement que tu vas être deux ordres de grandeur en dessous des objectifs.
        
        Regarde pourquoi les softs qui vont vite vont vite et tu as la réponse.
        
        Quand PHK "invente" le B-Heap pour Varnish, c'est pas 10 ans après. C'est qu'il sait ce qui va coûter cher pour son soft, il sait comment fonctionne un OS et la VMM et il design en conséquence pour en tirer parti.
        
        Quand Martin Thomson et ses potes concoivent le disruptor disruptor, ils connaissent très bien les problèmes qu'ont les autres approches. Ils concoivent dès le départ l'outil dont ils ont besoin pour créer leur archi.
        
        Quand Linus créé Git, il design le truc pour que ca réponde à son besoin de perf.
        
        Etc.
        
        Je trouve qu'ily'a une grosse part d'expérience là dedans. Tu commences par te faire niquer à rattraper ce que tu n'as pas prévu à la base à coup de profiling et micro-optim, puis petit à petit tu arrives de plus en plus à discerner les points clés de tes produits, les ordres de grandeurs, les piègres techniques de tes environnements, et à concevoir autour d'eux. Si en plus tu sais comment fonctionne une machine, un OS et ton runtime tu es le roi du monde.
        
        [^] # Re: quelques points
        
        Posté par Nicolas Boulay (site web personnel) le 18 juillet 2013 à 11:58. Évalué à -3.
        
        Si tu as d'énorme besoin de perf, tu ne commences pas par coder en java, et pourtant tout le monde le fait.
        
        "La première sécurité est la liberté"
        
        [^] # Re: quelques points
        
        Posté par ckyl le 18 juillet 2013 à 12:27. Évalué à 3. Dernière modification le 18 juillet 2013 à 12:29.
        
        Quel rapport avec la choucroute ?
        
        Ce que tu dis c'est que Martin Fowler, Martin Thomson, Trisha Gee, Michael Barker & les autres sont des cons incapables de choisir la techno ou le design qui répond à leur besoin ? Mince avec un peu de recul ca me parait pourtant être des gens extrêmement censés et compétents… Ou alors c'est plus général tu dis que tous les gens qui traitent de gros volume de données sont des crétins incapables ? Ca va autrement ?
        
        [^] # Re: quelques points
        
        Posté par Nicolas Boulay (site web personnel) le 18 juillet 2013 à 13:22. Évalué à -6.
        
        C'était purement gratuit. Java doit avoir le même genre de performance que "gcc -O0" et encore, tant que le garbage collector n'entre pas en compte.
        
        "La première sécurité est la liberté"
        
        [^] # Re: quelques points
        
        Posté par lasher le 19 juillet 2013 à 18:54. Évalué à 6.
        
        Tu ne codes ni n'utilises pas trop trop de programmes en Java toi, je me trompe ? :)
        
        [^] # Re: quelques points
        
        Posté par Nicolas Boulay (site web personnel) le 22 juillet 2013 à 09:50. Évalué à 2.
        
        Si justement :/
        
        "La première sécurité est la liberté"
        
        [^] # Re: quelques points
        
        Posté par djano le 02 août 2013 à 10:58. Évalué à 2. Dernière modification le 02 août 2013 à 10:59.
        
        Alors tu ne connais pas bien ta plateforme…
        
        Un conseil: change de langage de programmation.
        
        C'est typiquement ce dont ckyl parle: ne pas coder avec le cerveau debranche et puis arriver avec des gros problemes pour tout optimiser a la fin.
        
        [^] # Re: quelques points
        
        Posté par Nicolas Boulay (site web personnel) le 12 août 2013 à 10:22. Évalué à 3.
        
        On a très rarement le choix de la plateforme, surtout quand il y a un gros historique.
        
        "La première sécurité est la liberté"
        
        [^] # Re: quelques points
        
        Posté par psychoslave__ (site web personnel) le 23 juillet 2013 à 09:07. Évalué à 2.
        
        En même temps, tu as vite fait de généraliser ton code pour apporter une solution où la précision de correction est paramétrable, et qui n’est pas plus gourmande que la solution particulière. De plus si ton programme intervient dans l’ajustement de la trajectoire d’une fusée, tu veux de la précision ET de la performance.
        
        [^] # Re: quelques points
        
        Posté par LupusMic (site web personnel, Mastodon) le 18 juillet 2013 à 11:11. Évalué à 4.
        
        Donc ce n'est pas un problème d'utiliser des float pour gérer des comptes (d'argent) ? :-D
        
        [^] # Re: quelques points
        
        Posté par Nicolas Boulay (site web personnel) le 18 juillet 2013 à 11:59. Évalué à -4.
        
        Si tu as sur ton compte de quoi faire des overflow à 54 bits, cela commence à faire pas mal…
        
        "La première sécurité est la liberté"
        
        [^] # Re: quelques points
        
        Posté par claudex le 18 juillet 2013 à 12:17. Évalué à 9.
        
        Le problème des float, ce n'est pas le maximum mais les arrondis (le problème est le même, même si moins visible) avec les doubles.
        
        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
        
        [^] # Re: quelques points
        
        Posté par Nicolas Boulay (site web personnel) le 18 juillet 2013 à 13:21. Évalué à 0.
        
        C'est le fait que la mantisse est de 54 (je n'ai pas mis ce chiffre par hasard…) ou 24 bits qui te fait perdre des bis de précision, et cela n'a rien à voir avec le min et le max. Les arrondis de calcul sont assez bien maitrisés.
        
        "La première sécurité est la liberté"
        
        [^] # Commentaire supprimé
        
        Posté par Anonyme le 18 juillet 2013 à 15:02. Évalué à 5.
        
        Ce commentaire a été supprimé par l’équipe de modération.
        
        [^] # Re: quelques points
        
        Posté par Nicolas Boulay (site web personnel) le 18 juillet 2013 à 15:33. Évalué à 2.
        
        J'ai été un plus loin que ce document qui je connais depuis quelques années.
        
        C'est toujours agaçant de se faire moinser par des gens qui ne comprennent pas ce qu'ils font.
        
        Si ton nombre rentre dans la mantisse, tu as aucun soucis de plus que tu n'en aurais avec un entier. Point à la ligne. C'est si compliqué à comprendre ?
        
        Les arrondis round-to-even te répartissent au mieux les erreurs de calcul garanti à 1/2 LSB par calcul. C'est sûr que si tu t'amuses à mélanger des nombres énorme et tout petit, ton nombre ne rentre plus dans la mantisse et l'exposant rentre en jeu avec toutes les annulations de bits qui vont avec.
        
        Ensuite, les nombres IEEE, c'est de la "grosse merde", car ce n'est pas un corp, ni un anneau, tu ne peux pas faire des maths avec. C'est beaucoup plus simple de faire l'inverse : raisonner avec des nombres ayant un range et une précision à mapper sur des nombres flottants.
        
        "La première sécurité est la liberté"
        
        [^] # Re: quelques points
        
        Posté par lasher le 19 juillet 2013 à 18:59. Évalué à 3.
        
        J'aurais dû lire tout le thread avant de répondre tout à l'heure. ;)
        
        Je suis d'accord avec toi sur le fond. N'empêche qu'une bête réduction par exemple, ça peut complètement tuer la précision du calcul final. Donc n'importe quel programme parallèle (pour accélérer ma_compta v2.0 par exemple) risque de tout me casser si je ne passe pas par des entiers ou des nombres de précision arbitraire.
        
        [^] # Re: quelques points
        
        Posté par Nicolas Boulay (site web personnel) le 22 juillet 2013 à 09:53. Évalué à 2.
        
        Pas une compta, sauf si tu fais celle d'un pays. Avec un double, tu gères des nombres de plusieurs milliards sans perte de précision. Il faut juste éviter de passer en 32 bits pour aller plus vite…
        
        "La première sécurité est la liberté"
        
        [^] # Re: quelques points
        
        Posté par lasher le 23 juillet 2013 à 00:47. Évalué à 2.
        
        Mais si tu n'as pas de bol, et qu'un thread gère des « petites » sommes (exposant n, disons les dépenses quotidiennes), et qu'un autre thread gère des sommes plus grosses (exposant n', disons les salaires ou les chiffres du PMU, ou…), tu te retrouves avec des nombres d'ordres de grandeur potentiellement très différents.
        
        Plus « sérieusement » : j'ai donné des formations sur OpenMP. Forcément à un moment donné j'ai parlé des opérations de réduction. Un bête truc du genre produit scalaire :
        
        /* Algorithme non-optimisé pour le produit scalaire */ void dotproduct_omp(double * const sumref, double const * const A, double const * const B, const unsigned long N) { double sum = 0.0; #pragma omp parallel shared(A,B) { #pragma omp for default(none) reduction(+:sum) for (size_t i = 0; i < N; ++i) { sum += A[i] * B[i]; } } *sumref = sum; } #define N 100UL int main(void) { double *A = NULL, *B = NULL; unsigned long n = N, nbthreads = NUMTHREADS; double sum = 0.0; A = safe_malloc(sizeof(double) * N); B = safe_malloc(sizeof(double) * N); for (long i = 0; i < n; ++i) { A[i] = i; B[i] = n-i; } dotproduct_omp_atomic(&sum,A,B,n); printf("Parallel (OpenMP) dot product = %.2f\n", sum); free(A); free(B); return 0; }
        
        Bien entendu si toutes les valeurs de tes vecteurs sont peu ou prou du même ordre de grandeur, alors pas de problème. Mais si tu as de grandes disparités, même en double précision, alors la version séquentielle et la version parallèle vont sérieusement diverger pour le résultat final — et pas besoin de beaucoup de threads, je crois qu'au-delà de 4 on voyait déjà poindre les ennuis.
        
        [^] # Re: quelques points
        
        Posté par Nicolas Boulay (site web personnel) le 12 août 2013 à 10:27. Évalué à 2.
        
        " et pas besoin de beaucoup de threads, je crois qu'au-delà de 4 on voyait déjà poindre les ennuis."
        
        Si tu cherches à avoir exactement le même résultat, c'est évident. Mais dans un vrai système de la vrai vie, tu veux en général une précision fixe 10^-6 par exemple. Si tu changes l'ordre d'opération flottante, tu ne peux pas avoir le même résultat, les opérations IEEE754 ne sont pas commutatives, associative et autre propriété sympa des réels. Au mieux, tu auras le même résultat à x près.
        
        "La première sécurité est la liberté"
        
        [^] # Re: quelques points
        
        Posté par lasher le 12 août 2013 à 18:36. Évalué à 2.
        
        Non je parle bien de résultats allant au-delà d'un epsilon de différence. J'admets que la façon de remplir mes vecteurs était sans doute un peu extrême et que dans un cas « réel » les différences entre exposants ne serait sans doute pas aussi marquées. Cependant la différence entre une réduction séquentielle et parallèle peut être extrêmement grande en fonction de l'implémentation.
        
        [^] # Re: quelques points
        
        Posté par tyoup le 18 juillet 2013 à 15:04. Évalué à 2.
        
        Ah vous avez l'air de vous connaître. Peut-être pourrez-vous m'aider. J'essaye des fois de trouver des solutions à des problèmes simples malheureusement je suis visiblement trop c** pour y arriver. J'ai essayé de comprendre avec les floats, les doubles, les decimaux, les entiers mais rien n'y fait. Tenez, par exemple, un problème tout con à la base : partager un euro en 3. Et là…
        
        [^] # Re: quelques points
        
        Posté par Nicolas Boulay (site web personnel) le 18 juillet 2013 à 15:39. Évalué à 3.
        
        C'est vachement utile d'avoir le chiffre exact ! Avec 1/3, tu va avoir l'air malin pour faire tes sommes. Sinon, tu va en faire quoi de tes 10^-15 centimes ? Relis la citation de Linus posté ailleurs, (des fois, pi=3.14 suffit !)
        
        Donc, "et là", et bien on s'en tape, dans la vrai vie on a besoin d'un résultat final en 10^-5 euro.
        
        Et il n'y a pas besoin de "tout connaitre", il suffit de se renseigner un minimum sur ce que sont les nombres IEEE754.
        
        "La première sécurité est la liberté"
        
        [^] # Re: quelques points
        
        Posté par claudex le 18 juillet 2013 à 19:53. Évalué à 3.
        
        Le problème que tu n'as pas l'air de comprendre (ou qui te semble trop évident), c'est qu'il faut faire des arondi après chaque opération. Sinon, un euro divisé en 3 fois 3 ne donnera pas 1 euro. Et donc tout les calculs du genre 1== 1/3 * 3 sont cassés. Et tu n'as pas intérêt à arondir trop tôt ou trop tard dans ton code.
        
        Donc, "et là", et bien on s'en tape, dans la vrai vie on a besoin d'un résultat final en 10-5 euro.
        
        Pour les euros, c'est le cas, maitenant, dans la vrai vie, on a souvent des euros, des parts de tartes, des pourcentage de completion… Et il faut chaque fois se poser la question de où arondir pour ne rien casser.
        
        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
        
        [^] # Re: quelques points
        
        Posté par barmic le 19 juillet 2013 à 00:32. Évalué à 2.
        
        Et donc tout les calculs du genre 1== 1/3 * 3 sont cassés.
        
        Le mieux ne serait-il pas de faire du calcul formel à chaque fois ?
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Commentaire supprimé
        
        Posté par Anonyme le 19 juillet 2013 à 00:47. Évalué à 2.
        
        Ce commentaire a été supprimé par l’équipe de modération.
        
        [^] # Re: quelques points
        
        Posté par claudex le 19 juillet 2013 à 09:02. Évalué à 3.
        
        Ça risque de plomber les performances.
        
        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
        
        [^] # Re: quelques points
        
        Posté par Nicolas Boulay (site web personnel) le 19 juillet 2013 à 09:54. Évalué à 3.
        
        "Le problème que tu n'as pas l'air de comprendre (ou qui te semble trop évident), c'est qu'il faut faire des arondi après chaque opération"
        
        http://linuxfr.org/news/de-tout-de-rien-des-bookmarks-du-bla-bla-29#comment-1471335
        
        C'est pourtant 2 commentaires au dessus. Les arrondis en question sont très bien définit, et garantisse une sorte d'annulation de l'erreur. Les vrais problèmes se posent lors d'addition/soustraction de nombre de taille très différente.
        
        Ce que tu ne comprends pas, et que pourtant quelqu'un à très bien résumé avec une citation de Linus, est que la plus part du temps, on s'en fout que 1/3*3 != 1.0. En général on veut 1/3*3 - 1.0 < delta, avec delta = 10^-6 ou 10^-10. Cela dépend des usages. Toutes les maths sont faite ainsi sur ordinateur, regardes comment est codé la libm. Regardes l'astuce de la multiplication par une constante pour Doom pour éviter une division, c'est toujours le même principe : la précision est-elle suffisante ou pas.
        
        L'imprécision est même inclus dans les données d'entrée : il n'existe aucun "capteur absolue", il y a toujours une erreur estimable. Idem pour les effecteurs qui n'ont jamais de précision infini. Même les algorithmes de calcul sont souvent des approximations de la réalité (en simulation par exemple). Quel intérêt de faire des résultats avec 15 chiffres, quand l'algo ne peut en sortir que 6 ?
        
        Dans le cas de calcul monétaire, on veut juste que les résultats de compte finaux soit juste à quelques fractions de centime pret, mais c'est vrai qu'il est plus simple d'utiliser des grand entiers pour y arriver.
        
        "La première sécurité est la liberté"
        
        [^] # Re: quelques points
        
        Posté par claudex le 19 juillet 2013 à 09:59. Évalué à 5.
        
        Ce que tu ne comprends pas, et que pourtant quelqu'un à très bien résumé avec une citation de Linus, est que la plus part du temps, on s'en fout que 1/3*3 != 1.0
        
        Et bien, ce n'est pas ce que je vois, il y a plein de bug liés à ça parce que des développeurs n'ont pas fait gaffe et en fonction du dénominateur, ça marche ou pas. Alors, parfois c'est juste une barre de progression qui n'avance pas comme prévu, parfois c'est plus gênant.
        
        L'imprécision est même inclus dans les données d'entrée
        
        C'est vrai quand tu utilisateur un capteur. Ce n'est pas le cas quand tu pars d'un entier (somme d'argent, nombre de tarte, total à diviser en pourcentage (ça fait 1/quelque chose)…)
        
        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
        
        [^] # Re: quelques points
        
        Posté par Nicolas Boulay (site web personnel) le 19 juillet 2013 à 10:17. Évalué à 3.
        
        "total à diviser en pourcentage (ça fait 1/quelque chose)…)"
        
        C'est vrai, mais si c'est pour un affichage, tu te fou d'une erreur inférieur à 10^-3. La division par zéro, c'est encore autre chose. L'erreur existe, avec des maths pure, les entiers, ce n'est pas spécifiques au flottant.
        
        Je me rappelle des discussions de codeurs audio qui vantaient les entiers 64 bits, avec lequel ils faisaient du virgule fixe, avec 16 bit sous la virgule et donc tout un tas de contraintes sur les opérations.(j'ai codé de la trigonométrie en virgule fixe sur µP, c'était pas drôle) Tout cela parce que les float 32 bits, avec 24 bits de mantisse ont forcément des erreurs inclus. Aujourd'hui, vu la demande de puissance, des algos audio peuvent entièrement être codé en double, avec un code beaucoup plus simple.
        
        "La première sécurité est la liberté"
        
        [^] # Re: quelques points
        
        Posté par claudex le 19 juillet 2013 à 10:31. Évalué à 3.
        
        C'est vrai, mais si c'est pour un affichage, tu te fou d'une erreur inférieur à 10-3.
        
        Oui, mais il faut penser à faire round(maVar*100) == 25(ou>=) pour afficher un truc à 25% et non pas fairemaVar >= 0.25(parce que tu peux être à 0.2499999). Mais c'est vrai que ce n'est pas grave, ça peut juste mener à un affichage un peu bizarre.
        
        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
        
        [^] # Re: quelques points
        
        Posté par Nicolas Boulay (site web personnel) le 19 juillet 2013 à 11:04. Évalué à 4.
        
        Utiliser "==" avec un float ?! Ouch. C'est à éviter.
        
        "La première sécurité est la liberté"
        
        [^] # Re: quelques points
        
        Posté par claudex le 19 juillet 2013 à 11:58. Évalué à 3.
        
        C'est tout le problème du float et il n'y pas de ≃ ou de ≳ dans la plupart des langages de programmation.
        
        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
        
        [^] # Re: quelques points
        
        Posté par Nicolas Boulay (site web personnel) le 19 juillet 2013 à 12:13. Évalué à 3.
        
        De toute façon, il faut définir soi-même le delta. J'aimerais tellement voir un langage de programmation qui gère des réel avec range et prévision. Tout un tas de transformation resterait valide (de mémoire, c'est encore un anneau ou un corps). Une fois simplifié, tout est transformé en code flottant.
        
        "La première sécurité est la liberté"
        
        [^] # Re: quelques points
        
        Posté par lasher le 19 juillet 2013 à 19:20. Évalué à 3.
        
        Oui enfin, n'importe quel prof un peu sérieux qui te parle de la manipulation des nombres à virgule flottante te dira qu'on ne compare jamais directement deux flottants comme ça :
        
        if (float1 == float2) { // bad programmer, no cookie! ... }
        
        … Mais plutôt comme ceci :
        
        #define DELTA 0.00001 if (float2-float1 < DELTA) { ... } /* on pourrait meme imaginer une macro: */ #define FLT_CMP(a,b) ( (a)-(b) < DELTA )
        
        Bref, dès qu'on parle de maths avec nombres réels/complexes, on est obligé de passer par quelques précautions élémentaires. Le compilo peut aider pour tout ce qui est calcul sur constantes (mêmes à virgules flottantes), mais l'utilisateur doit faire le reste.
        
        [^] # Commentaire supprimé
        
        Posté par Anonyme le 22 juillet 2013 à 09:24. Évalué à 4.
        
        Ce commentaire a été supprimé par l’équipe de modération.
        
        [^] # Re: quelques points
        
        Posté par lasher le 19 juillet 2013 à 18:58. Évalué à 3.
        
        Pas que. Même avec 54 bits, si d1 et d2 ont des exposants très différents, tu vas au devant de gros, gros, gros soucis niveau arrondis…
        
        [^] # Re: quelques points
        
        Posté par Nicolas Boulay (site web personnel) le 22 juillet 2013 à 09:54. Évalué à 2.
        
        on parle de nombre dans un range entre 0.001 et 1 milliard. Les exposants seront très similaires.
        
        "La première sécurité est la liberté"
        
        [^] # Re: quelques points
        
        Posté par LupusMic (site web personnel, Mastodon) le 18 juillet 2013 à 14:02. Évalué à 3.
        
        Disons que j'ai déjà vu des applications où tout était compter en float, et évidement, à la fin, les comptes étaient faux en raison de l'emploi de float dans le code.
        
        Il y a une obligation légale à ce que les comptes soient exacts.
        
        [^] # Re: quelques points
        
        Posté par Nicolas Boulay (site web personnel) le 18 juillet 2013 à 14:53. Évalué à 2.
        
        Il y a bien des gens qui font des comptes avec excel sachant qu'excel rajoute une couche intermédiaire de sérialisation/déserialisation vers du décimal (pour rappel 0.1 ne s'exprime pas en nombre flottant).
        
        "La première sécurité est la liberté"
        
        [^] # Commentaire supprimé
        
        Posté par Anonyme le 18 juillet 2013 à 15:08. Évalué à 2.
        
        Ce commentaire a été supprimé par l’équipe de modération.
        
        [^] # Re: quelques points
        
        Posté par Nicolas Boulay (site web personnel) le 18 juillet 2013 à 15:46. Évalué à 3.
        
        Oui, mais c'est de la capiloquadrisectomie. β = 10 en hardware ne doit exister que pour le machine Power d'IBM. Sur x86, cela doit être plus simple d'utiliser une bibliothèque numérique de précision étendu.
        
        Par flottant, j'entendais double ou float, dans le sens de C. :)
        
        "La première sécurité est la liberté"
        
        [^] # Commentaire supprimé
        
        Posté par Anonyme le 18 juillet 2013 à 15:53. Évalué à 3.
        
        Ce commentaire a été supprimé par l’équipe de modération.
        
        [^] # Re: quelques points
        
        Posté par Nicolas Boulay (site web personnel) le 18 juillet 2013 à 16:05. Évalué à 2.
        
        Oui mais dans la réalité, ce n'est pas le cas.
        
        "La première sécurité est la liberté"
        
        [^] # Re: quelques points
        
        Posté par lasher le 19 juillet 2013 à 19:22. Évalué à 2.
        
        Bah, remplace C par Fortran alors. ;-)
        
        [^] # Re: quelques points
        
        Posté par LupusMic (site web personnel, Mastodon) le 18 juillet 2013 à 15:12. Évalué à 1.
        
        Prends moi pour un con. Comme si je ne saivais pas qu'on avait inventé les nombres flottant parce que les ordinateurs ne comprennent pas les décimaux du système décimal de manière native, et que donc il faut ruser pour avoir des calculs exacts.
        
        Microsoft Excel, à l'instar de bases de données relationnelles, de Python, de la libbc, etc, doit certainement offrir un support des nombres décimaux de manière exacte. Qu'ils utilisent les float dans leur soupe n'est pas un problème, si les algos employés permettent de détecter les cas limites.
        
        [^] # Re: quelques points
        
        Posté par Nicolas Boulay (site web personnel) le 18 juillet 2013 à 15:43. Évalué à 2.
        
        Bah non, justement (et là, je peux te prendre pour un con, ce qui n'était le cas avant). Excel s'amuse (s'amusait ?)à écrire et relire ses cases, des chaine de caractère, et donc à faire les conversions pour faire des calculs en flottant en base 2. Je n'ai jamais parler de la raison d'être des flottants, encore heureux que tu saches à quoi cela sert.
        
        Les décimaux flottant existent mais sont très peu utilisé (sauf machine IBM) et je serais curieux de voire comment elles sont supporté sous x86.
        
        "La première sécurité est la liberté"
        
        [^] # Re: quelques points
        
        Posté par Nicolas Boulay (site web personnel) le 18 juillet 2013 à 15:50. Évalué à 1.
        
        "Comme si je ne saivais pas qu'on avait inventé les nombres flottant parce que les ordinateurs ne comprennent pas les décimaux du système décimal de manière native"
        
        En plus, c'est complètement faux. Les premières machines savaient compter en base 10 (cf les calculs BCD). Le calcul binaire est simplement plus efficace d'un point de vue hardware (en taille/vitesse/consomation).
        
        C'est plus simple pour ne pas faire de bétises, d'avoir des nombres flottant décimaux pour faire des applications financières, d'ou le support par IBM sur leur grosse machine.
        
        "La première sécurité est la liberté"
        
        [^] # Re: quelques points
        
        Posté par LupusMic (site web personnel, Mastodon) le 18 juillet 2013 à 18:12. Évalué à 1.
        
        Je me suis mal exprimé. Il n'est pas possible de représenter directement un nombre décimal, sauf entiers, en nombre binaire comme on le fait avec les nombres entiers.
        
        Il faut adopter une représentation différente, comme avec le BCD que tu indiques (et que je ne savais pas exister, mais c'était à peu près ce que j'avais imaginé pouvoir faire), ou sacrifier de la fiabilité sur l'autel de la performance (note que je n'ai rien contre le fait d'utiliser les float en science, où il faudra incorporer leur imprécision dans la détermination de l'imprécision du résultat).
        
        En fin de compte (sic), on est assez d'accord. C'est juste que tu considère qu'un centime d'erreur dans un compte de plusieurs centaines de milliers de franc ce n'est rien. Mais mon tympant se souvient encore du mécontentement d'une cliente, qui a passé avec moi des heures au téléphone pour un centime d'erreur, simplement parce que les bons comptes font les bons services publics. :D
        
        [^] # Re: quelques points
        
        Posté par Nicolas Boulay (site web personnel) le 19 juillet 2013 à 09:59. Évalué à 3.
        
        "(note que je n'ai rien contre le fait d'utiliser les float en science, où il faudra incorporer leur imprécision dans la détermination de l'imprécision du résultat)."
        
        Demande à Alenvers, de mémoire, c'est son boulot, et évidement qu'il en tient compte.
        
        "qu'un centime d'erreur dans un compte de plusieurs centaines de milliers de franc ce n'est rien. Mais mon tympant se souvient encore du mécontentement d'une cliente, qui a passé avec moi des heures au téléphone pour un centime d'erreur, simplement parce que les bons comptes font les bons services publics. :D"
        
        2⁵⁴ (un double), c'est 10^16, ce n'est pas une erreur sur 100 000 ! De plus, les erreurs de centimes (toujours dans le même sens) pour faire croire à une erreur informatique, les grosses boites appellent cela du "pricing". On a un prix annoncé de 30€ ttc, puis il donne le prix HT, puis calcul des taxes, et le prix à payé devient 30.01€ et non plus le prix ttc de la pub.
        
        "La première sécurité est la liberté"
        
        [^] # Re: quelques points
        
        Posté par barmic le 17 juillet 2013 à 14:26. Évalué à 4.
        
        Je ne vais pas te contredire c'est juste la base de la base. Autrement tu n'es pas développeur mais membre de la compagnie créole ;)
        
        C'est marrant j'ai la vision totalement inverse. Je ne sais pas comment c'est ailleurs, mais en France n'importe qui a un bac+3 en info a mangé 3 ans de développement. Par contre je ne connais pas de formation à bac+3 qui fait faire des tests. À bac+5 je ne connais pas beaucoup de formation qui ont font faire des tests sérieusement (plus d'un semestre, en parlant réellement de la reproductibilités des tests, de TDD/BDD, de technique de test d'interface etc) et je ne parle pas d'intégration continue, si un étudiant connait c'est parce qu'il s'y est intéressé de lui même (donc peu de chance qu'il ai vu la manière de les gérer et leur maintien).
        
        J'ai pas de stat' mais j'ai pas l'impression que les tests soient quelque chose de vraiment pris au sérieux (ça prend du temps, c'est chiant, ça crée pas de valeur (sic)).
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: quelques points
        
        Posté par maboiteaspam le 17 juillet 2013 à 14:40. Évalué à 2.
        
        J'ai pas de stat' mais j'ai pas l'impression que les tests soient quelque chose de vraiment pris au sérieux (ça prend du temps, c'est chiant, ça crée pas de valeur (sic)).
        
        Le test n'est pas forcément chiant, mais les sujets testés peuvent être rédhibitoire à une expérience agréable.
        Pris au sérieux c'est un développement à part entière du livrable, certains aiment, d'autre pas (…) .
        Et non, triple non, le test créé de la valeur par sa reproductibilité. Mais oui, ce n'est pas un investissement qui fais pousser l'argent….
        
        [^] # Re: quelques points
        
        Posté par Slauncha (site web personnel) le 17 juillet 2013 à 17:05. Évalué à 1.
        
        Par contre la vision uniquement plomberie du job "yatoudanlélib" va finir par faire vraiment des ravages.
        
        Ton point de vue, que je partage, me rappelle ce billet pour l'accroche en français. Sinon le billet original
        
        There’s a whole mindset - a modern movement - that solves things in terms of working out how to link together a constellation of different utility components like noSQL databases, frontends, load balancers, various scripts and glue and so on. Its not that one tool fits all; its that they want to use all the shiny new tools. And this is held up as good architecture! Good separation. Good scaling.
        
        [^] # Re: quelques points
        
        Posté par barmic le 17 juillet 2013 à 17:46. Évalué à 3.
        
        Ouai c'est un coup de gueule d'un aigris un vendredi matin qui pleurniche parce que beaucoup de projet se font avec du web et qu'il n'est pas content.
        
        Utiliser des bibliothèques ou des langages de haut niveau c'est à peut près pareil. Il faut juste savoir ce qu'on utilise et être capable de le remettre en cause quand c'est nécessaire.
        
        Il faudrait tomber dans le travers inverse et faire du NIH. Le problème de la mauvaise utilisation de certaines bibliothèques par manque de connaissance se résolvent par l'apprentissage des spécificités de la bibliothèque en question et pas forcément par l'interdiction de l'utiliser.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
    - [^] # Re: quelques points
      
      Posté par Pierre Tramonson le 19 juillet 2013 à 12:03. Évalué à 0.
      int[] montableau = {1,2,3,4}; Arrays.sort(montableau);
      
      ça devrait faire ce que tu veux.
      http://docs.oracle.com/javase/7/docs/api/java/util/Arrays.html#sort%28int[]%29
      - [^] # Re: quelques points
        
        Posté par ckyl le 19 juillet 2013 à 12:37. Évalué à 2. Dernière modification le 19 juillet 2013 à 12:38.
        
        Tu me prends pour un âne ou tu tiens à entretenir la réputation qui va avec ton pseudo ? ;)
        
        trier une liste d'entiers selon un comparateur adhoc en Java
        
        Typiquement tu utilises un type primitif pour faire du packing de plusieurs valeurs. Tu mets ce type primitif dans un tableau, puis tu veux le trier ou faire une dichotomie selon une valeur packée.
        
        Comme souvent, tu ne peux spécifier un Comparator que pour des objets par ce qu'ils ne veulent pas livrer X implémentations copier/coller pour les types primitifs (merci la VM/autoboxing de merde !).
        
        Utiliser l'autoboxing pour ca, ca veut dire payer 12 bytes d'overhead mémoire pour 4 bytes de données pour chaque élément, plus le coût CPU, plus faire exploser la génération de garbage. C'est vite risible.
        
        En Java c'est game over tu le fais à la main et tu réécris le même code pour la millième fois. D'autres langages de la JVM sont capables de prendre en charge la génération de ce code pourri pour te le rendre transparent (y'a pas de magie non plus).
        
        [^] # Re: quelques points
        
        Posté par claudex le 19 juillet 2013 à 13:57. Évalué à 4.
        
        En Java c'est game over tu le fais à la main et tu réécris le même code pour la millième fois.
        
        Après 5 fois, j'aurais déjà écrit une lib…
        
        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
        
        [^] # Re: quelques points
        
        Posté par ckyl le 19 juillet 2013 à 14:11. Évalué à 3.
        
        Encore une porte ouverte enfoncée ! J'aime bien la propension de prendre les autres pour des brêles sur ce fil ;)
        
        C'est ce que tu finis par faire et ca à ses propres problèmes:
        
        Tu ne libs pas des trucs sans usage massif et vérifié. Autrement tu rentres dans un autre problème qui est la gestion de la compatibilité et du design. Une fois que tu as des clients ta bouse tu ne la modifies plus. Ca coûte pas du tout la même chose à concevoir et maintenir que du code planqué quelque part à côté du métier.
        
        Que tu te retrouves avec 100 libs. Chacune fait des trucs aucune tout. La gestion des versions dans le produit final est l'enfer. Et quand tu rajoutes les évolutions du langage ca devient vraiment très marrant (Java 8 + Guava est un plaisir…). Au niveau "macro" Guava + Commons est l'exemple type. En micro, chaque équipe/projet fait ses libs et en 2 ans c'est très rigolo (autrement retour au premier point).
        
        Mais je te supporte dans la démarche d'utiliser un exemple précis sans voir large pour pouvoir dire des généralités ;)
        
        [^] # Re: quelques points
        
        Posté par Zylabon le 20 juillet 2013 à 14:14. Évalué à 2.
        
        Sinon t'utilise un vrai langage qui sait faire les trucs stupides tout seul :)
        
        import Data.List as L type Taille = Int data Sexe = Homme Taille | Femme deriving (Eq,Ord,Show) data Personne = Personne { nom :: String , age :: Int , sexe :: Sexe } deriving (Eq, Ord, Show) liste_personnes = [ Personne "Vincent" 42 (Homme 15) , Personne "Anne" 32 Femme ] main = print $ L.sort liste_personnes
        
        Bon, il faut quand même lui dire qu'il a le droit d'inventer un ordre pour les type que tu lui décrit.
        
        Please do not feed the trolls
        
        [^] # Re: quelques points
        
        Posté par Pierre Tramonson le 19 juillet 2013 à 14:05. Évalué à 4.
        
        :)
        Plus sérieusement si tu en es à ce niveau d'optimisation, c'est que tu n'as plus grand chose d'autre à optimiser, voire que tu as du temps à perdre…
        (sauf bien sur si tu te balades avec des tableaux de dizaines/centaines de milliers d'entiers, mais là le problème est peut être en amont).
        
        Après il faut bien admettre que tout ne peut pas être dans l'API standard, et que des choix ont été faits (Comparator sur les Objets par ex).
        Il y a des cas où ça te fait vraiment ch** ok, mais rien ne t'empêche de le coder à la main.
        
        [^] # Re: quelques points
        
        Posté par ckyl le 19 juillet 2013 à 16:11. Évalué à 3.
        
        Plus sérieusement si tu en es à ce niveau d'optimisation, c'est que tu n'as plus grand chose d'autre à optimiser, voire que tu as du temps à perdre…
        
        Oui, on me paie par ce que c'est cool de perdre du temps sur des trucs totalement inutiles pas par ce que mon boulot à un sens !
        
        sauf bien sur si tu te balades avec des tableaux de dizaines/centaines de milliers d'entiers
        
        Tu es sur la bonne piste.
        
        Quand tu sors de la "webapp lambda" ou du script, tu as souvent ce genre de contraintes:
        
        - SLA type X rêquetes/s ou jitter < 40ms
        - Besoins business qui poussent très fort la technique
        - Ne pas gacher XXXK€ de matos quand ca coûte moins cher à fixer en soft
        - Etc.
        
        C'était bien le sens de mon message à la base sur "yatoudanlélib". Finalement ayant bossé dans quelques secteurs/technos différents, j'ai toujours eu à me sortir les doigts sur l'algorithmique et l'implémentation à un moment ou l'autre. C'est aussi ca qui fait la différence entre une bouse et un truc qui marche ou qui coute 100x plus cher en ops. Notre métier c'est de comprendre ce qu'on attend et de proposer ce qui semble le meilleur choix, c'est un équilibre entre:
        - Penser "hors de la boîte" pour prendre le problème de la manière la plus intelligentes ou enlever les contraintes non dures.
        - Du design de haut niveau
        - Du design de bas niveau
        - Savoir coder
        - Savoir ne pas coder et acheter du matos
        
        Si la solution simple fait le job, on fait la solution simple et on passe à la suite.
        
        Pour mon métier actuel ca veut aussi dire: Est ce qu'on optimise du code séquentiel par ce qu'en grattant un ou deux ordres de grandeurs ca va passer ou est ce qu'on distribue le tout sur X machines (le coût en engineering se pose la aussi) ? Un footprint mémoire x4 ou x9 ca peut aussi vouloir dire passer d'une machine à XXX, tu te mets à taper du disque et du réseau alors que c'était CPU bound et le coût en matos est pas linéaire du tout. Ou simplement ne plus être capable de livrer ce qu'on te demande.
        
        sauf bien sur si tu te balades avec des tableaux de dizaines/centaines de milliers d'entiers, mais là le problème est peut être en amont
        
        Oh tu recommences à me prendre pour un âne ;) Tu veux jouer ?
        
        Il y a des cas où ça te fait vraiment ch** ok, mais rien ne t'empêche de le coder à la main.
        
        Bien sur. Si tu remontes la discussion, tu verras que c'est ce que je fais et que tu me proposais une juste solution impossible à un exemple particulier ;)
        
        Maintenant si je ne codais qu'un sort par ce que y'a pas dans la lib standard je me ferais bien chier…
        
        [^] # Re: quelques points
        
        Posté par barmic le 19 juillet 2013 à 15:40. Évalué à 2.
        
        Je ne comprends pas très bien le problème que tu soulève.
        Tu as des outils inclus dans la bibliothèque standard, ceux-ci ne conviennent pas à ton usage. Tu t'en crée d'autres.
        
        Ce qui te gêne c'est qu'il y ai un outil dans la bibliothèque standard pour ça ? Tu préfèrerais ne rien avoir et avoir quelque chose de probablement moins testé (tout le monde ne fait pas autant de tests que le JCK et n'a pas autant d'utilisateurs qu'une JVM).
        
        C'est un choix, c'est ce qui est fait avec le C où la bibliothèque standard est minimaliste.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: quelques points
        
        Posté par ckyl le 19 juillet 2013 à 16:47. Évalué à 2.
        
        Je ne comprends pas très bien le problème que tu soulève.
        
        Je ne soulève aucun problème à la base sur ce sujet.
        
        Je réponds sur une réponse erronée, et souligne le pourquoi du comment. C'est un problème très classique découlant de choix très discutables fait il y a des années par la JVM/Java 5 et que tu ne peux pas ignorer si tu fais autre chose que lancer du code.
        
        Ne cherche pas a rattacher cela à la discussion initiale sauf par le fait que manipuler des types primitifs en grand nombre c'est fréquent. Un jour tu as certainement recodé pleins de structures de données à la main par ce que y'a zob par défaut.
        
        Après y'a des centaines d'autres raisons d'aller "bas niveau". Tout comme tu vas forcément finir par aller te frotter aux problèmes courants de la JVM et du langage "tout le monde" à les mêmes problèmes.
# LESS VS Sass

Posté par fero14041 le 17 juillet 2013 à 10:27. Évalué à 2.

Une autre différence, à mes yeux importante, entre Sass et LESS tient dans l'existence de bouquin(s) pour le premier et pas pour le second. Il en existe un chez The Pragmatic Bookshelf: "Pragmatic guide to Sass", et un autre devrait être publié sous peu chez Manning: "Sass and Compass in Action".
- [^] # Re: LESS VS Sass
  
  Posté par CrEv (site web personnel) le 17 juillet 2013 à 10:32. Évalué à 2.
  
  Et on pourrait aussi dire que l'un des avantages de Sass c'est Compass.
- [^] # Re: LESS VS Sass
  
  Posté par Tequila_Yuen le 17 juillet 2013 à 15:56. Évalué à 2.
  
  Packt a Instant LESS CSS Preprocessor How-to
  - [^] # Re: LESS VS Sass
    
    Posté par fero14041 le 17 juillet 2013 à 16:46. Évalué à 1.
    
    Ah, merci pour la référence :-)
# 38 – La ligne de métro 2 de Moscou (Russie)

Posté par Anonyme le 17 juillet 2013 à 10:50. Évalué à 4.

On jurerais que des monstres sortis tout droit de Metro 2033 vont nous arriver dessus.

Chouttes ces photos, mais pour l’église Saint-Etienne-le-Vieux, ne serait-ce pas une vue artistique plus que la réalité ?
- [^] # Re: 38 – La ligne de métro 2 de Moscou (Russie)
  
  Posté par Tony Flow le 22 juillet 2013 à 11:28. Évalué à 2.
  
  Chouttes ces photos, mais pour l’église Saint-Etienne-le-Vieux, ne serait-ce pas une vue artistique plus que la réalité ?
  
  C'est en effet un collage réalisé par un artiste (http://www.jurgroessen.nl/pages/obscur).
  Dommage ça avait de la gueule avec le cours d'eau… bon de toute façon on ne peut la voir que d'extérieur…
# Object Calisthenics mouai

Posté par ckyl le 17 juillet 2013 à 12:00. Évalué à 3.

Je suis tombé (ouille) sur cet article vraiment intéressant, sur une façon de (bien) faire de la programmation par objet : Object Calisthenics.

Je suis assez dubitatif. Ce sont, il me semble, des règles de bon sens, mais les utiliser comme pratique me semble assez ardu.

Je bosse actuellement sur l'implémentation de ca, algo page 8. J'ai un peu réfléchi comment je ferais en suivant "bêtement" les règles. Je n'arrive pas à être convaincu d'un quelconque progrès…
- [^] # Re: Object Calisthenics mouai
  
  Posté par CrEv (site web personnel) le 17 juillet 2013 à 12:05. Évalué à 3.
  
  Je bosse actuellement sur l'implémentation de ca, algo page 8
  
  Forcément si tu n'y mets pas un peu du tiens ! ;-)
  
  Plus sérieusement, je vois ces règles pour les objets "classiques", pas pour les (gros) algos. Et comme tu le dis, il s'agit surtout de bon sens. D'ailleurs je trouve que certaines règles ne sont pas forcément bonnes, genre limiter à deux membres. C'est bien sur les cas d'écoles, mais dans la vrai vie tu as quand même souvent une structure complexe, logique, propre qui en contient plus.
  
  Et de toute façon, appliquer bêtement les règles ça ne marche que très rarement ;-)
  
  Mais celles-ci peuvent faire une base assez correcte pour bosser, tant qu'on n'est pas dans une grosse complexité algorithmique, dans ce cas le problèmes est tout autre à mon avis.
  - [^] # Re: Object Calisthenics mouai
    
    Posté par ckyl le 17 juillet 2013 à 12:18. Évalué à 2.
    
    C'est justement la forme qui me pose problème. Avancer ca comme une méthode avec des règles, plutôt qu'en conseil me semble contre productif.
    
    Par exemple, dire que couper le flux d'exécution par des return sur les conditionnels ou éviter les flux parallèles aide souvent à la lisibilité me semble une bonne chose. Par contre la facon de le dire me semble aller trop loin.
    
    Il me semble que la cible du truc n'est pas forcément ceux qui ont beaucoup de bouteille, ce sont des choses relativement simples et banales, et la facon qu'ils ont de le dire peut faire du mal sans recherche d'équilibre.
    - [^] # Re: Object Calisthenics mouai
      
      Posté par LupusMic (site web personnel, Mastodon) le 17 juillet 2013 à 15:18. Évalué à 2.
      
      Ce n'est malheureusement pas du bon sens. N'oublions pas que le bon sens est la logique du pauvre : c'est évident, donc c'est vrai. Bien souvent, l'évidence est l'ennemi du développeur.
      
      Et tout le monde ne partage pas le même "bon sens". Certains vont considérer un return par fonction comme étant du bon sens. D'autres vont considérer qu'il faut sortir le plus tôt possible (bien sûr, en C, on peut sortir le plus tôt possible et un seul return avec un goto). Ceux qui m'ont moinsé allègrement dans une discussion sur du code PHP pourri sont de la seconde école.
      
      Donc oui, il faut l'écrire. Mais il faut aussi le justifier, sinon ça ne sert à rien.
      - [^] # Re: Object Calisthenics mouai
        
        Posté par CrEv (site web personnel) le 17 juillet 2013 à 15:50. Évalué à 2.
        
        une discussion sur du code PHP pourri
        
        Tu as un pointeur ? ;-)
        
        Donc oui, il faut l'écrire. Mais il faut aussi le justifier, sinon ça ne sert à rien
        
        Oui, et il faut aussi que ce soit pertinent vis à vis du contexte. Les règles ne s'appliquent pas toujours de la même manière dans tous les domaines. Par exemple dans un domaine critique, je verrais surtout de petites méthodes, très facilement testables, peu de profondeur dans chacune, etc. Parfois dans de la glue, du code non métier, le problème et l'intérêt peut varier.
        
        [^] # Re: Object Calisthenics mouai
        
        Posté par LupusMic (site web personnel, Mastodon) le 18 juillet 2013 à 11:18. Évalué à 1.
        
        Je ne trouve plus où je me suis disputé à propos du choix de retourner dès que possible ou en un seul point. Ce ne doit pas être si récent que ça ^{^;}
        
        [^] # Re: Object Calisthenics mouai
        
        Posté par LupusMic (site web personnel, Mastodon) le 18 juillet 2013 à 11:35. Évalué à 1.
        
        Finalement j'ai retrouvé : https://linuxfr.org/nodes/98225/comments/1450176
# Deux petites typos

Posté par CrEv (site web personnel) le 17 juillet 2013 à 13:03. Évalué à 3.
- [NIH] (les [] sont en trop)
- « Don't get demoralized by bad estimates ! »
  
  La forme initiale estimates! n'est-elle pas correcte ? En anglais il n'y a pas d'espace devant la ponctuation, non ? Après, vu que c'est inséré dans un texte français, je ne sais pas comment on doit l'écrire.
Et sinon, merci aux correcteurs, j'avais essayé de le nettoyer avant mais j'ai vu que j'avais laissé certaines erreurs donc merci encore.
- [^] # Re: Deux petites typos
  
  Posté par Benoît Sibaud (site web personnel) le 17 juillet 2013 à 13:46. Évalué à 2.
  
  Corrigé, merci.
# Web Components

Posté par zebul0n (site web personnel) le 17 juillet 2013 à 13:05. Évalué à 1.

Merci pour la présentation concernant les "web components", très intéressant !

J'imagine qu'il va falloir patienter un bon moment en tout cas afin de pouvoir les utiliser.
- [^] # Re: Web Components
  
  Posté par CrEv (site web personnel) le 17 juillet 2013 à 15:42. Évalué à 2.
  
  Ça c'est sur que ça reste un problème…
  
  Maintenant, disons qu'on peut limiter la casse en fixant des règles au niveau des navigateurs supportés (genre les firefox depuis le dernier ESR, les 2 ou 3 derniers chrome, les 2 derniers IE uniquement, etc)
  Avec ça tu peux faire du grand public, du perso, voir même du pro si tu vise un parc "correct" (oui je sais certains se mettent enfin à IE7 mais bon…)
  De toute façon ce n'est que de cette manière que les choses avanceront réellement.
# 10 ans...

Posté par maboiteaspam le 17 juillet 2013 à 14:31. Évalué à 4.

Oui c'est vrai que le web avance lentement. Mais je de bonnes raisons d'augurer l'avenir sous de bons auspices.
10 années en arrière mon sentiment est qu'on est resté bloquer dans ces frameworks mvc tout collé à la db, qui tiennent mal la charge, sont difficile à tester, mais voilà, répondent au besoin pressant de faire de l'argent.
Depuis dix ans les smartphones ont largement envahit nos métiers du web. Et avec eux une vague de nouveautés car tout d'un coup, il me semble, l'industrie n'était plus empêtré avec Microsoft et ces exploits, en 10 versions…. Le problème, amha, c'est que jusque maintenant tout cela est resté cantonné au mobile.
Le desktop ne bénéficie que tardivement de cette vague. Hors, j'ai le sentiment que le changement s'opère en ce moment.
Le cloud n'est plus un nuage d'idées et bonnes intentions, mais une réponse concrètement implémentable demain, l’environnement de développent web devient moins agressifs (reste plus qu'ie8 et se sera plié), les acteurs majeures peaufinent leurs implémentations (css3, html5, vidéo, webgl), et les consommateurs (société éditrice de site oueb) voient dans le cloud une raison de provoquer une migration de plateforme. De plus l'avènement du fameux m-commerce pousse celles ci à se frotter au problème du multi device de manière très frontale, et donc amha à faire chauffer le standard w3c.
On peut, il me semble, espérer du bon de tout cela.

Sur la même période on peut remarquer que javascript à regagner ces lettres de noblesses, voir le travail de douglas crockford qui, il me semble, a permit de faire comprendre cette ovni des langages de programmation.

Par contre ouais, un site web reste un site web…. un constat aussi plat que chiant à vivre.

Mais bon il est de bons exemples pour peut être nous indiquer que tout n'est pas perdu et qu'avec de l'imagination on peut faire des choses sympa, à ce titre je te cites : http://geelen.github.io/web-directions-talk/#35
Citons aussi les doodles de google que j'admires.
- [^] # Re: 10 ans...
  
  Posté par LupusMic (site web personnel, Mastodon) le 17 juillet 2013 à 15:23. Évalué à 1.
  
  Peux-tu citer un framework web MVC qui a au moins 10 ans ?
  - [^] # Re: 10 ans...
    
    Posté par CrEv (site web personnel) le 17 juillet 2013 à 15:44. Évalué à 2.
    
    Pas tout à fait mais Rails a 9 ans. C'est pas si mal que ça, non ?
    - [^] # Re: 10 ans...
      
      Posté par fero14041 le 17 juillet 2013 à 16:51. Évalué à 1.
      
      Et avec (presque) 8 ans déjà: Django (21 juillet 2005, dixit Wikipédia)
      - [^] # Re: 10 ans...
        
        Posté par CrEv (site web personnel) le 17 juillet 2013 à 16:59. Évalué à 3.
        
        Et voilà encore une fois la preuve de la supériorité des technologies ruby sur python !!
        
        Mais si je vous promet qu'on est vendredi !
        
        [^] # Re: 10 ans...
        
        Posté par Sytoka Modon (site web personnel) le 17 juillet 2013 à 20:20. Évalué à 4.
        
        Enfin, il me semble que Zope a révolutionner le web à l'époque. Après, son interface en mode web quasi exclusivement lui a fait beaucoup de mal. D'après wikipedia -> 1998
        
        https://en.wikipedia.org/wiki/Zope
        
        [^] # Re: 10 ans...
        
        Posté par LupusMic (site web personnel, Mastodon) le 18 juillet 2013 à 11:30. Évalué à 1.
        
        Ce qui me déplaisait fortement à l'époque, c'était le paradigme de sauvegarde systématique dans la base de données de l'instance applicative. Et puis, il faut avouer que j'avais déjà du mal à gérer C et PHP, alors ajouter un autre langage par dessus ça me faisait un peu peur. Je sais aujourd'hui que c'était une erreur, mais bon, il faut en faire.
        
        Bref, je n'ai dû entendre parler de MVC qu'en 2003/2004, quand la mode a atteint PHP. Donc oui, pour moi MVC et le web, c'est bientôt 10 ans, mais pas tout à fait :-D J'avais déjà entendu parler d'architecture 3-tiers, mais pour moi ça désignait la trinité front-back-rdb, plus ou moins.
  - [^] # Re: 10 ans...
    
    Posté par Tequila_Yuen le 17 juillet 2013 à 16:03. Évalué à 3.
    
    Est-ce que Jakarta Struts est assez MVC pour toi ?
    En 2001, l'article Introduction to Jakarta Struts Framework dit
    
    Struts is a Model-View-Controller (MVC) framework compatible with Sun's J2EE platform and primarily based on servlet and JSP technology. The Struts framework has been around for about a year now and was originally conceived by Craig McClanahan. Struts is now part of the Jakarta project (which is part of ASF, the Apache Software Foundation).
    
    Dixit Wikipedia, Craig McClanahan, son createur, l'a donne a l'Apache Foundation en Mai 2000
    - [^] # Re: 10 ans...
      
      Posté par CrEv (site web personnel) le 17 juillet 2013 à 16:06. Évalué à 2.
      
      Oui mais est-ce qu'il est toujours utilisé ? ;-)
      - [^] # Re: 10 ans...
        
        Posté par Tequila_Yuen le 17 juillet 2013 à 17:03. Évalué à 1.
        
        en maintenance d'appli, helas oui.
    - [^] # Re: 10 ans...
      
      Posté par LupusMic (site web personnel, Mastodon) le 18 juillet 2013 à 11:30. Évalué à 3.
      
      C'est surtout du Java, il n'y a que des gens sérieux qui font du Java.
  - [^] # Re: 10 ans...
    
    Posté par lasher le 17 juillet 2013 à 18:37. Évalué à 2. Dernière modification le 17 juillet 2013 à 18:38.
    
    Struts?
    
    Edit: grillé. :)
- [^] # Re: 10 ans...
  
  Posté par khivapia le 17 juillet 2013 à 15:40. Évalué à 3.
  
  Mis à part les fautes de grammaire, je ne peux que plussoyer. Ça tombe de source.
  
  Sachons regarder la voix du progrès, qui poursuivant son droit chemin tourne résolument ses pas vers un avenir meilleur.
  - [^] # Re: 10 ans...
    
    Posté par Guillaume Denry (site web personnel) le 17 juillet 2013 à 16:47. Évalué à 10.
    
    Ça tombe de source.
    
    Tu veux dire, "ça coule sous le sens" ?
    - [^] # Re: 10 ans...
      
      Posté par khivapia le 17 juillet 2013 à 22:45. Évalué à 4.
      
      Oups, je m'ai gourré. Je m'en mords les dents.
- [^] # Re: 10 ans...
  
  Posté par CrEv (site web personnel) le 17 juillet 2013 à 16:04. Évalué à 4.
  
  En fait c'est surtout que au final j'ai l'impression qu'on passe notre temps à refaire la même chose.
  On cherche sur pas mal de plans à résoudre encore et toujours les mêmes problèmes, typiquement faire évoluer les composants de base (listes déroulantes, avoir des onglets, etc). XUL, Flex, WPF/E étaient par certains côtés des tentatives d'améliorations de cela.
  
  Alors oui, il y a beaucoup de choses plus intéressantes, javascript est bien plus important, la programmation côté serveur est toujours plus "agréable" par exemple. L'interface évolue aussi, on a des meilleurs inputs (date, mail, etc, gestion d'élément requis dans un formulaire, layout, etc). Mais d'un autre côté rien ne change. Les outils sont meilleurs mais bon, c'est tout de même un peu toujours le même problème qu'avant.
  
  Peut-être est-ce moi qui ait une mauvaise vision du monde du web, c'est une possibilité. Peut-être ne vois-je pas le chemin accompli mais beaucoup plus le chemin qu'il resterait à accomplir.
  - [^] # Re: 10 ans...
    
    Posté par maboiteaspam le 18 juillet 2013 à 13:04. Évalué à 1.
    
    Tu me fais penser a feu douglas engelbart qui dit qu'on à passé les 40 dernières années à ré inventer ce que lui avait déjà en '58.
    voir le post http://linuxfr.org/users/eqfm/journaux/les-murguettes-en-deuil#comment-1468656
    
    Maintenant web ou client lourd, les deux utilisent le même sets de composants de base et cherche juste le meilleur d'exprimer le besoin en une réponse informatique easy-to-develop-and-debug. liste déroulante, case à cocher, champ texte ils ne changeront peut être pas avant longtemps. Pas avant l'avènement de l'humain connecté (the humancentipad cf southpark). Et même là, il faudra bien représenté ce que notre esprit peut utiliser, alors utiliserons d'autres moyens que la textbox. Je sais pas…
    
    Du coup oui ça tourne en rond, c'est toujours la même chose…
    
    un peu déprimant : )
    
    PS à tlm : désolé les fautes, promit je fais de mon mieux…. ce serait plus simple avec un bon debugger.. : )
# Merci

Posté par _jordan_ le 17 juillet 2013 à 22:59. Évalué à 4.

Et oui, après une (beaucoup trop) longue absence

Effectivement, j'attendais ce nouveau numéro. Merci à toi.
- [^] # Re: Merci
  
  Posté par daeldir le 18 juillet 2013 à 01:26. Évalué à 2.
  
  Ben de ma part, pas merci du tout ⸮
  
  J'ai une de ces quantité de lecture maintenant… CrEv, tu pourrais pas trouver de sujets et des documents moins intéressants ?
  - [^] # Re: Merci
    
    Posté par CrEv (site web personnel) le 18 juillet 2013 à 10:37. Évalué à 6.
    De rien, content d'occuper ton temps libre ;-)
    
    CrEv, tu pourrais pas trouver de sujets et des documents moins intéressants ?
    
    Si ce n'est que ça, on doit pouvoir s'arranger !
    Voici donc les liens que je ne placerai pas dans une prochaine news (trop vieux, moins intéressants, juste pas envie, etc) :
    
    Devel
    - A better way to learn AngularJS : http://www.thinkster.io/
    - Welcome to the wonderful world of noBackend where frontend developers build full stack apps, without thinking about the backend : http://nobackend.org/
    - La boite à outils de la parallaxe : http://www.webdesignertrends.com/2012/07/la-boite-a-outils-de-la-parallaxe/
    - 3dxml (format d'échange 3D, plutôt orienté CAO) : http://www.3ds.com/fr/products-services/3dvia/3d-xml/00/
    - De l'artisanat aux bases de l'industrialisation : http://fr.slideshare.net/tut_tuuut/de-lartisanat-aux-bases-de-lindustrialisation avec une vidéo planquée au milieu d'un billet sur les braguettes… (désolé Agnès ;-) http://ploque.net/plok/2013/07/ce-quon-ne-dit-pas-dans-les-bouquins-sur-la-grossesse/
    Misc
    - Toyota Kata an alternative to agile restrospectives : http://hakanforss.wordpress.com/2012/04/25/agile-lego-toyota-kata-an-alternative-to-retrospectives/
    - Kanban : faire des promesses que vous pouvez tenir : http://blog.xebia.fr/2013/06/12/kanban-faire-des-promesses-que-vous-pouvez-tenir/
    - Infographie sur le secteur aéronautique : http://www.grouperandstad.fr/files/img_grf/pdf/Infographie_Aeronautique_fleuron_de_lindustrie_francaise.pdf
    - Les ATR 600 étendent leur rayon d'action : http://www.usinenouvelle.com/article/les-atr-600-etendent-leur-rayon-d-action.N198648
    - Travailler sur ses deux pieds (prez pour vanter les mérites de la position debout pour travailler) : http://real34.github.io/slides/travailler-sur-ses-deux-pieds/#/
    - La compétitivité et la France, une grande histoire d'amour depuis la fin des années 90 : http://www.usinenouvelle.com/article/competitivite-une-etude-souligne-le-decrochage-de-la-france-depuis-1997.N198040
    - Innovation Jugaad : Redevenons ingénieux : http://www.amazon.fr/Innovation-Jugaad-Redevons-ing%C3%A9nieux-Radjou/dp/2354560966 (d'ailleurs si quelqu'un a un retour sur ce livre ça m'intéresse vraiment)
    - La relation entre Atlassian et les recruteurs (ça me donne aussi l'envie d'écrire un billet un peu dans le même genre, mais entre un candidat - moi - et les recruteurs…) : https://www.atlassian.com/company/careers/recruiters
    Graphisme, design, photos, etc
    - Asiles abandonnés : http://io9.com/six-abandoned-asylums-with-genuinely-chilling-backstori-512154481
    - Des stations de métro justes… sublimes : http://io9.com/eye-poppingly-gorgeous-underground-stations-from-around-508669563
    Voilou, j'espère que je t'ai bien pourri tout ton temps libre avec tout ça, à la prochaine ! :-p
    - [^] # Re: Merci
      
      Posté par Joël Thieffry (site web personnel) le 18 juillet 2013 à 13:45. Évalué à 1.
      
      Je ne te remercie pas, je vais devoir prendre un jour de congés pour dépiler tout ça. Un peu comme pour chaque sortie d'une nouvelle version du kernel Linux.
    - [^] # Re: Merci
      
      Posté par Sytoka Modon (site web personnel) le 18 juillet 2013 à 18:20. Évalué à 2.
      
      Il y a la station Arts et Métiers, c'est la seule de Paris mais j'en étais sur !
- [^] # Re: Merci
  
  Posté par CrEv (site web personnel) le 18 juillet 2013 à 10:18. Évalué à 2.
  
  Merci à toi :-) Avec de la chance le prochain sera dans un peu moins longtemps…
# de tout, de rien, des commentaires, des roguelike...

Posté par fravashyo le 18 juillet 2013 à 11:17. Évalué à 3.

Puisqu'on parle ici de javascript, je voulais vous parler d'un petit système de jeu roguelike qui utilise js, et qui permet donc d'en créer dans un navigateur, ça s'appelle rot.js et son créateur est à mon sens un génie du javascript (il suffit d'aller voir le reste de son site ici : http://ondras.zarovi.cz/) :

http://ondras.github.io/rot.js/hp/

Un exemple de jeu particulièrement réussi réalisé avec rot.js, avec une vraie histoire, et un bon challenge (jeu assez facile néanmoins) : http://ondras.zarovi.cz/games/trw/

Et puisqu'on parle de roguelike, et que l'article évoquait les grilles hexagonales, je voulais vous présenter ce jeu qui utilise une géométrie non euclidienne pour représenter l'espace, ça s'appelle hyperrogue : http://roguetemple.com/z/ (une version android existe également)

Si vous aimez moyennement les roguelike avec 70 commandes à apprendre, ceci est un pour vous ici vous avez un principe très simple à appliquer, avec néanmoins quelques découvertes agréables et un niveau de rejouabilité important.

Hydra est super également (et aussi sur android) mais on sort du sujet, bien que le thème soit assez mathématique : il faut tuer des hydres en tenant compte de la capacité de l'arme actuellement en main qui pourra couper un certain nombre de têtes et pas plus pas moins, sinon des têtes vont repousser.

« I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond