La discussion point par point est assez vaine par ce que tu trouveras toujours un moyen de te passer d'une chose donnée et que ca évolue vite des deux côtés. En fait c'est un ensemble utilisabilité, fonctionnalité, pérennité (très important dès que tu as une partie non destructive ce que n'a pas Gimp par exemple). La meilleur chose à faire si tu as un peu de temps, c'est de chopper les versions d'essai, de lire un bon bouquin sur avoir un workflow photographique et de te faire une idée par toi même. Ça ne salit pas, et ca permet de comprendre les différences si on s'en donne les moyens (pas 5 minutes). Perso je l'ai fait après avoir longtemps utiliser les solutions libre, et prorio sous Linux; et je n'en suis jamais revenu.
Si la photographie t'intéresse, alors va plus voir du côté de lightroom qui à suffisamment évolué pour presque toujours se suffit à lui même. Il devient de plus en plus rare d'avoir à passer par Photoshop (et pour un photographe Photoshop elements permet de faire presque la même chose pour 1/10 du prix).
Ceci est mon dernier commentaire puisque ça ne débouchera sur rien. Mais pour parler uniquement de ce que je connais parfaitement comparer Photoshop, et les outils associés, à gimp ou krita empêche tout simplement d'être pris au sérieux. Ce qui ne veut pas dire qu'ils ne répondent pas à certaines utilisations.
Maintenant ca me semble une démarche parfaitement compréhensible et valable de vouloir garder certains logiciels qui ne sont pas portables. Quels qu'ils soient et pour quelque raison personnelle que ça soit.
Le portage de Git sous Windows est réalisé à l'aide de Msys. Les performances sont désastrueuses. Je m'en servais sur un très gros logiciel chez mon employeur
Je connais pas mal de gens qui utilisent git sous Windows de beaucoup de façon différentes (cygwin, intégration IDE et autres) sans soucis. La taille des projets est du même ordre de grandeur que toi, un poil moins par ce qu'en général c'est découpé en paquet qui doivent tournés à 1M.
je me disais que l'Apple machin n'allait pas forcément trop avec la présentation d'une distribution Linux,
L'idée n'est pas de séparer matériel et logiciel ? Si le matos convient à l'utilisation tant mieux
je tombe un peu de haut en voyant que certaines d'entre elles montrent que Wine permet de faire tourner Foxit Reader, ou encore Dreamweaver ! (passons pour Photoshop)
Jamais utilisé Foxit donc je n'ai pas d'avis si c'est pertinent ou pas. Pour les deux autres que tu cites ce n'est pas débile du tout vu qu'à ma connaissance il n'y pas pas d'équivalent. Il y a donc sûrement des gens intéressés pour la fonctionnalité.
Bref quand vous en aurez marre de tirer sur tout ce qui vous plait pas, pensez à faire des trucs constructif plutôt que le politburo.
Sachant que même sans protection, de nombreux algorithme marche la plupart du temps, je ne ferais pas le même constat que toi.
Même un développeur web a besoin de comprendre le principe d'asynchronisme quand il va écrire ses tests Selenium où il va lancer une ou des actions dont il va devoir attendre la fin avant de valider. Comme il n'y a pas de primitives de synchronisation efficaces possibles, tu voudrais une barrière, entre les deux parties il va se l'implémenter à la main avec un busy wait (cf. FluentWait). Si le mec n'a pas compris ca, il va faire de la merde avec des suites de tests totalement instables et non déterministes. Ce n'est qu'un exemple parmi des tas.
Mais en même temps la programmation ca ne s'arrête pas à pisser du code frontend dans un framework. Autrement tu en arrives au syndrome du "codeur PHP". Et dès que tu sors de ce cadre tu as forcément des choix à faire en terme de design qui t'imposent de comprendre et la base de la base théorique et des technos avec lesquels tu travailles. Autrement tu passes ton temps a faire des trucs qui tombent en marche. Donc oui pour moi ce sont des concepts fondamentaux à notre époque.
Non. Par contre soit tu écris toujours du code séquentiel, soit t'as intérêt à connaître les bases de chez base du sujet. On est en 2012, les machines parallèles et les systèmes asynchrones sont partout. Ces concepts doivent être maîtrisé par n'importe quel programmeur et non plus seulement système.
Donc dans un sens il a raison. Si tu découvres ca par hasard dans un journal soit tu fais parti d'un public non technique qui n'aura jamais à s'en servir, soit ça fait des années que tu fais n'importe quoi et que tu n'as lu aucune bouquin ou aucune documentation traitant du sujet sur lequel tu travailles. Et si c'est pour éduquer la masse il existe moultes excellent bouquin/articles sur le sujet selon le domaine.
Bha ce sont juste des évidences. Si t'as besoin de préciser ca c'est même pas la peine d'aller plus loin; ca sera de la merde de toute façon les mecs seront incapable de te sortir un truc qui tient debout.
Maintenant limiter les machine de test/validation/intégration (et pas de dev…) tout seul ca sert à rien si t'as pas un scénario de test qui tient la route et les métriques qui vont bien. Et ca c'est pas évident surtout quand tu commences à bosser sur de vrais trucs qui font tout un tas de chose plus compliqués qu'un CGI à papa qui pisse un html à partir d'une petite db.
Ne me fait pas dire ce que je n'ai pas écris. La majorité sont plutôt mauvais, mais au moins ils sont censés avoir quelques rudiments d'informatique (au sens science) et de ne pas avoir appris à coder sur commentcamarche. Ce qui fait qu'au final ce que tu énonçais dans ton commentaire devrait n'être qu'un énorme enfoncage de porte ouverte, autrement c'est la porte.
J'ai dit "bon ingénieur" ca veut dire ce que ca veut dire. Et ce n'était clairement pas le point intéressant de mon message…
Par exemple, un bon développeur indente son code, le commente, utilise des noms de variables explicite, etc. Le module, à l'inverse va supprimer l'indentation, les commentaires, raccourcir les noms des variables, etc.
T'es sérieux ? Tu penses vraiment que quelqu'un pourrait penser à utiliser des noms de variable court pour gagner de la place ou n'utiliser qu'un seul fichier source ? Le bon développeur il ne livre pas le code source du repository en production. Il y a une phase de construction qui optimise toute la partie JS (ou plus) spécialement pour l'application finale, et produire un artifact qui sera utilisé pour la prod. Il faut bien distinguer le code source de ce qui est exécuté, même si dans le cas de JS le langage source et cible sont les mêmes.
Je viens de regarder le code, le @license qui est un tag standard jslint est préservé par le service pagespeed mais pas par le mod_pagespeed. Les seuls commentaires que préserve mod_pagespeed sont les "conditional compilation" d'IE. Donc pour le moment si tu veux préserver la licence il faut la faire passer pour une "conditional compilation".
Bon supporter le @license c'est un patch de moins de 10 lignes à leur envoyer. Ou si tu veux faire ton truc, c'est pas bien plus compliqué faut juste voir pour les perfs en fonction de l'heuristique.
Non il compte tout les fichiers. C'est tellement grossier comme métrique qu'elle ne sert à rien; déjà que le nombre de lignes de code ne veut pas dire grand chose. Autrement pour rester dans les mesures inutiles, systemd c'est un peu plus gros que rsyslog en LOC C… Du coup c'est énorme ou pas ?
Tu fais comme pour le milliard d'autres options et de différences qui existent quand tu fais du multiplate-forme. Sois tu utilises le plus petit dénominateur commun des inits (c'est à dire ce que tu faisais avec tes anciens scripts) et là le portage systemd c'est 5 minutes. Soit tu décides de tirer parti des fonctionnalités offertes par une plateforme et tu protèges ce code et prévois un mode dégradé quand les fonctionnalités ne sont pas la.
Si tu n'arrives pas à faire de mode dégradé c'est à priori signe qu'il manquait quand même quelque chose.
Vous sortez d'une autre planète ou quoi ? Red Bull ne se cache de rien du tout, c'est leur business model depuis 10 à 15 ans et ils ne s'en cachent pas. Leur énorme budget pub ils le passent à sponsoriser des trucs funs ou extrêmes. Sur tout les events qu'ils organisent ou pro qu'ils sponsorisent c'est exactement la même chose.
Après savoir si ca sert à quelque chose ou à rien. J'ai envie de dire que si ca sert à rien on devrait supprimer tout budget attribué aux filières sportives de haut niveau… Après toi tu n'en as peut être rien a faire.
Il y a tellement peu de choses qui servent à quelque chose! Et plutôt que de claquer sa thune en spot TV qui ne sert vraiment à rien, red bull la claque en sponsorisant à peu prêt tout les sports d'images qui peuvent exister. On peut voir ca comme une façon bien moins débile et inutile de claquer son budget pub…
Si il est autant rejeté pourquoi la plupart des distros l’intègrent petit à petit et pourquoi l'effort pour le dégager est si marginal ? Si ça pose tant de problème que ça y'en a bien deux ou trois qui vont finir par se sortir les doigts plutôt que de vocaliser non ? Tout ce qui a fait avancer les choses est parti de la. Des mecs qui ont cherché à résoudre leur problème.
Le problème c'est que la plupart de ceux qui parlent n'ont jamais essayé ou essayer de lire la doc et de se former. C'est dommage ca pourrait donner des discutions plus intéressantes… Mais critiquer est bien plus à la mode que contribuer.
Ça te permet quand même de voir si tu as un script qui bouffe de la mémoire, ou est trop long à s'éxécuter ou part dans une boucle d'appels infinie.
Non. La plupart du temps on bosse avec une pile logicielle, des configurations, et des environnements totalement différents de ce qui va tourner en prod. Penser que tu vas trouver quoi que ce soit de non trivial en bridant grossièrement les devs est plutôt une utopie.
Pour te dire, quand tu bosses tu utilises souvent un OS différent de la prod, avec un serveur non supporté, avec une db non supportée, avec un browser non supporté, avec une config de l'appli, du serveur et des libs 100% différentes de la prod, avec des libs backend et frontend en debug, avec des ressources servies par des gros hack et le tout sans latence, en utilisant une seule page, avec un jeu de donnée ridicule, et en ayant tout hacké pour développer efficacement ton objectif en cours. Bref essayer de tirer une conclusion de ce que tu observes sur ton poste de travail en sachant qu'il est impossible d'extrapoler le comportement en situation réelle c'est perdre son temps.
Ce genre de problèmes ça se réfléchi au moment de la conception et de l'implémentation et ça se valide en déployant et testant en condition déterminées. La façon de faire peut énormément varier selon le type de projet, la méthodologie et l'organisation des équipes.
Après le web c'est plein de branle couilles, de PHP warriors et de serial cut&pasters. Mais c'est pas en leur foutant une machine pourrie que tu vas en faire des bons ingénieurs…
le contextes de dev doit limiter les ressources plus fortement que le contexte de prod
Mouais. La plus grosse différence entre les environnements de dev et la prod c'est que les devs bossent à latence 0 et ça ça change tout. Limiter les ressources sur les machines des devs ca ne sert vraiment pas à grand chose. On passe par des chemins d'exécutions qui n'ont rien à voir, des configurations très différentes et une charge ridicule. Faut juste faire les tests de charge sur des machines réalistes avec des scénarios réalistes.
mais j'ai peur que ça incite les développeurs de tels site à ne surtout rien faire par ce que c'est plus facile d'installer un truc que de ce remettre en cause
En même temps si ça fait le boulot… C'est comme tout, il faut analyser la chose pour voir ce que ça fait exactement et comment, puis décider de ce qu'on peut lui déléguer ou non. Dans l'évolution de toute technologie on commence par devoir tout maîtriser puis laisser petit à petit l’environnement certains tâches qu'il peut faire aussi bien que nous mais plus rapidement et pour moins cher.
[^] # Re: Sautons dedans
Posté par ckyl . En réponse au journal Linux Deepin…. Évalué à 3.
La discussion point par point est assez vaine par ce que tu trouveras toujours un moyen de te passer d'une chose donnée et que ca évolue vite des deux côtés. En fait c'est un ensemble utilisabilité, fonctionnalité, pérennité (très important dès que tu as une partie non destructive ce que n'a pas Gimp par exemple). La meilleur chose à faire si tu as un peu de temps, c'est de chopper les versions d'essai, de lire un bon bouquin sur avoir un workflow photographique et de te faire une idée par toi même. Ça ne salit pas, et ca permet de comprendre les différences si on s'en donne les moyens (pas 5 minutes). Perso je l'ai fait après avoir longtemps utiliser les solutions libre, et prorio sous Linux; et je n'en suis jamais revenu.
Si la photographie t'intéresse, alors va plus voir du côté de lightroom qui à suffisamment évolué pour presque toujours se suffit à lui même. Il devient de plus en plus rare d'avoir à passer par Photoshop (et pour un photographe Photoshop elements permet de faire presque la même chose pour 1/10 du prix).
[^] # Re: Sautons dedans
Posté par ckyl . En réponse au journal Linux Deepin…. Évalué à 8.
Ceci est mon dernier commentaire puisque ça ne débouchera sur rien. Mais pour parler uniquement de ce que je connais parfaitement comparer Photoshop, et les outils associés, à gimp ou krita empêche tout simplement d'être pris au sérieux. Ce qui ne veut pas dire qu'ils ne répondent pas à certaines utilisations.
Maintenant ca me semble une démarche parfaitement compréhensible et valable de vouloir garder certains logiciels qui ne sont pas portables. Quels qu'ils soient et pour quelque raison personnelle que ça soit.
[^] # Re: perforce :-(
Posté par ckyl . En réponse au journal [PUB] Mon employeur recrute - Boston area - Software Performance. Évalué à 2.
Je connais pas mal de gens qui utilisent git sous Windows de beaucoup de façon différentes (cygwin, intégration IDE et autres) sans soucis. La taille des projets est du même ordre de grandeur que toi, un poil moins par ce qu'en général c'est découpé en paquet qui doivent tournés à 1M.
# Sautons dedans
Posté par ckyl . En réponse au journal Linux Deepin…. Évalué à 8.
L'idée n'est pas de séparer matériel et logiciel ? Si le matos convient à l'utilisation tant mieux
Jamais utilisé Foxit donc je n'ai pas d'avis si c'est pertinent ou pas. Pour les deux autres que tu cites ce n'est pas débile du tout vu qu'à ma connaissance il n'y pas pas d'équivalent. Il y a donc sûrement des gens intéressés pour la fonctionnalité.
Bref quand vous en aurez marre de tirer sur tout ce qui vous plait pas, pensez à faire des trucs constructif plutôt que le politburo.
[^] # Re: Pourquoi ?
Posté par ckyl . En réponse au journal Les sémaphores. Évalué à 3.
Même un développeur web a besoin de comprendre le principe d'asynchronisme quand il va écrire ses tests Selenium où il va lancer une ou des actions dont il va devoir attendre la fin avant de valider. Comme il n'y a pas de primitives de synchronisation efficaces possibles, tu voudrais une barrière, entre les deux parties il va se l'implémenter à la main avec un busy wait (cf. FluentWait). Si le mec n'a pas compris ca, il va faire de la merde avec des suites de tests totalement instables et non déterministes. Ce n'est qu'un exemple parmi des tas.
Mais en même temps la programmation ca ne s'arrête pas à pisser du code frontend dans un framework. Autrement tu en arrives au syndrome du "codeur PHP". Et dès que tu sors de ce cadre tu as forcément des choix à faire en terme de design qui t'imposent de comprendre et la base de la base théorique et des technos avec lesquels tu travailles. Autrement tu passes ton temps a faire des trucs qui tombent en marche. Donc oui pour moi ce sont des concepts fondamentaux à notre époque.
[^] # Re: ARgh, trillons pourris
Posté par ckyl . En réponse au journal Ramesh Raskar et l’imagerie à un trillion d’images par seconde.. Évalué à 4. Dernière modification le 17 octobre 2012 à 14:07.
Avec les tablettes et smartphones ca reprend tout son sens.
[^] # Re: ARgh, trillons pourris
Posté par ckyl . En réponse au journal Ramesh Raskar et l’imagerie à un trillion d’images par seconde.. Évalué à 3.
C'est et c'était la corbeille, pas poubelle ;)
[^] # Re: Pourquoi ?
Posté par ckyl . En réponse au journal Les sémaphores. Évalué à 2.
Non. Par contre soit tu écris toujours du code séquentiel, soit t'as intérêt à connaître les bases de chez base du sujet. On est en 2012, les machines parallèles et les systèmes asynchrones sont partout. Ces concepts doivent être maîtrisé par n'importe quel programmeur et non plus seulement système.
Donc dans un sens il a raison. Si tu découvres ca par hasard dans un journal soit tu fais parti d'un public non technique qui n'aura jamais à s'en servir, soit ça fait des années que tu fais n'importe quoi et que tu n'as lu aucune bouquin ou aucune documentation traitant du sujet sur lequel tu travailles. Et si c'est pour éduquer la masse il existe moultes excellent bouquin/articles sur le sujet selon le domaine.
[^] # Re: ARgh, trillons pourris
Posté par ckyl . En réponse au journal Ramesh Raskar et l’imagerie à un trillion d’images par seconde.. Évalué à 0.
Les Français ? Qui sait ils arrêteraient peut être de se tirer une balle dans le pied
[^] # Re: Chaudière à uranium et caféine
Posté par ckyl . En réponse à la dépêche Mod_pagespeed : un accélérateur de pages Web. Évalué à 3. Dernière modification le 15 octobre 2012 à 17:54.
Bha ce sont juste des évidences. Si t'as besoin de préciser ca c'est même pas la peine d'aller plus loin; ca sera de la merde de toute façon les mecs seront incapable de te sortir un truc qui tient debout.
Maintenant limiter les machine de test/validation/intégration (et pas de dev…) tout seul ca sert à rien si t'as pas un scénario de test qui tient la route et les métriques qui vont bien. Et ca c'est pas évident surtout quand tu commences à bosser sur de vrais trucs qui font tout un tas de chose plus compliqués qu'un CGI à papa qui pisse un html à partir d'une petite db.
[^] # Re: Chaudière à uranium et caféine
Posté par ckyl . En réponse à la dépêche Mod_pagespeed : un accélérateur de pages Web. Évalué à 2.
Ne me fait pas dire ce que je n'ai pas écris. La majorité sont plutôt mauvais, mais au moins ils sont censés avoir quelques rudiments d'informatique (au sens science) et de ne pas avoir appris à coder sur commentcamarche. Ce qui fait qu'au final ce que tu énonçais dans ton commentaire devrait n'être qu'un énorme enfoncage de porte ouverte, autrement c'est la porte.
J'ai dit "bon ingénieur" ca veut dire ce que ca veut dire. Et ce n'était clairement pas le point intéressant de mon message…
[^] # Re: Réellement efficace ?
Posté par ckyl . En réponse à la dépêche Mod_pagespeed : un accélérateur de pages Web. Évalué à 1.
T'es sérieux ? Tu penses vraiment que quelqu'un pourrait penser à utiliser des noms de variable court pour gagner de la place ou n'utiliser qu'un seul fichier source ? Le bon développeur il ne livre pas le code source du repository en production. Il y a une phase de construction qui optimise toute la partie JS (ou plus) spécialement pour l'application finale, et produire un artifact qui sera utilisé pour la prod. Il faut bien distinguer le code source de ce qui est exécuté, même si dans le cas de JS le langage source et cible sont les mêmes.
[^] # Re: Pourquoi ?
Posté par ckyl . En réponse au journal Les sémaphores. Évalué à 8.
Oui depuis les gens ne savent plus coder ni les concepts fondamentaux de l'informatique ;)
[^] # Re: Est-ce compatible avec les licences d'utilisation ? (Minifying)
Posté par ckyl . En réponse à la dépêche Mod_pagespeed : un accélérateur de pages Web. Évalué à 2. Dernière modification le 15 octobre 2012 à 11:07.
Je viens de regarder le code, le @license qui est un tag standard jslint est préservé par le service pagespeed mais pas par le mod_pagespeed. Les seuls commentaires que préserve mod_pagespeed sont les "conditional compilation" d'IE. Donc pour le moment si tu veux préserver la licence il faut la faire passer pour une "conditional compilation".
http://code.google.com/p/page-speed/source/browse/lib/trunk/src/pagespeed/js/js_minify.cc#248
Bon supporter le @license c'est un patch de moins de 10 lignes à leur envoyer. Ou si tu veux faire ton truc, c'est pas bien plus compliqué faut juste voir pour les perfs en fonction de l'heuristique.
[^] # Re: Est-ce compatible avec les licences d'utilisation ? (Minifying)
Posté par ckyl . En réponse à la dépêche Mod_pagespeed : un accélérateur de pages Web. Évalué à 2. Dernière modification le 15 octobre 2012 à 10:23.
Genre comme ca: https://developers.google.com/speed/docs/pss/OptimizeJavaScript ?
[^] # Re: Parallèle avec dragonfly
Posté par ckyl . En réponse à la dépêche Archlinux utilise désormais systemd par défaut pour les nouvelles installations. Évalué à 2.
Non il compte tout les fichiers. C'est tellement grossier comme métrique qu'elle ne sert à rien; déjà que le nombre de lignes de code ne veut pas dire grand chose. Autrement pour rester dans les mesures inutiles, systemd c'est un peu plus gros que rsyslog en LOC C… Du coup c'est énorme ou pas ?
[^] # Re: Et la compatibilité
Posté par ckyl . En réponse à la dépêche Archlinux utilise désormais systemd par défaut pour les nouvelles installations. Évalué à 7.
Tu fais comme pour le milliard d'autres options et de différences qui existent quand tu fais du multiplate-forme. Sois tu utilises le plus petit dénominateur commun des inits (c'est à dire ce que tu faisais avec tes anciens scripts) et là le portage systemd c'est 5 minutes. Soit tu décides de tirer parti des fonctionnalités offertes par une plateforme et tu protèges ce code et prévois un mode dégradé quand les fonctionnalités ne sont pas la.
Si tu n'arrives pas à faire de mode dégradé c'est à priori signe qu'il manquait quand même quelque chose.
[^] # Re: Meilleure qualité
Posté par ckyl . En réponse au journal Opération Red Bull Stratos . Évalué à 5.
Vous sortez d'une autre planète ou quoi ? Red Bull ne se cache de rien du tout, c'est leur business model depuis 10 à 15 ans et ils ne s'en cachent pas. Leur énorme budget pub ils le passent à sponsoriser des trucs funs ou extrêmes. Sur tout les events qu'ils organisent ou pro qu'ils sponsorisent c'est exactement la même chose.
Après savoir si ca sert à quelque chose ou à rien. J'ai envie de dire que si ca sert à rien on devrait supprimer tout budget attribué aux filières sportives de haut niveau… Après toi tu n'en as peut être rien a faire.
[^] # Re: Meilleure qualité
Posté par ckyl . En réponse au journal Opération Red Bull Stratos . Évalué à 10.
Il y a tellement peu de choses qui servent à quelque chose! Et plutôt que de claquer sa thune en spot TV qui ne sert vraiment à rien, red bull la claque en sponsorisant à peu prêt tout les sports d'images qui peuvent exister. On peut voir ca comme une façon bien moins débile et inutile de claquer son budget pub…
[^] # Re: Parallèle avec dragonfly
Posté par ckyl . En réponse à la dépêche Archlinux utilise désormais systemd par défaut pour les nouvelles installations. Évalué à 8.
Si il est autant rejeté pourquoi la plupart des distros l’intègrent petit à petit et pourquoi l'effort pour le dégager est si marginal ? Si ça pose tant de problème que ça y'en a bien deux ou trois qui vont finir par se sortir les doigts plutôt que de vocaliser non ? Tout ce qui a fait avancer les choses est parti de la. Des mecs qui ont cherché à résoudre leur problème.
Le problème c'est que la plupart de ceux qui parlent n'ont jamais essayé ou essayer de lire la doc et de se former. C'est dommage ca pourrait donner des discutions plus intéressantes… Mais critiquer est bien plus à la mode que contribuer.
[^] # Re: Parallèle avec dragonfly
Posté par ckyl . En réponse à la dépêche Archlinux utilise désormais systemd par défaut pour les nouvelles installations. Évalué à 10.
Tu confonds rapport de bug et la beugler avec la meute. Y'en a qui saisissent encore la différence.
[^] # Re: Chaudière à uranium et caféine
Posté par ckyl . En réponse à la dépêche Mod_pagespeed : un accélérateur de pages Web. Évalué à 2.
Enfin bref de toute facon on est au niveau hello world là.
[^] # Re: Chaudière à uranium et caféine
Posté par ckyl . En réponse à la dépêche Mod_pagespeed : un accélérateur de pages Web. Évalué à 8.
Non. La plupart du temps on bosse avec une pile logicielle, des configurations, et des environnements totalement différents de ce qui va tourner en prod. Penser que tu vas trouver quoi que ce soit de non trivial en bridant grossièrement les devs est plutôt une utopie.
Pour te dire, quand tu bosses tu utilises souvent un OS différent de la prod, avec un serveur non supporté, avec une db non supportée, avec un browser non supporté, avec une config de l'appli, du serveur et des libs 100% différentes de la prod, avec des libs backend et frontend en debug, avec des ressources servies par des gros hack et le tout sans latence, en utilisant une seule page, avec un jeu de donnée ridicule, et en ayant tout hacké pour développer efficacement ton objectif en cours. Bref essayer de tirer une conclusion de ce que tu observes sur ton poste de travail en sachant qu'il est impossible d'extrapoler le comportement en situation réelle c'est perdre son temps.
Ce genre de problèmes ça se réfléchi au moment de la conception et de l'implémentation et ça se valide en déployant et testant en condition déterminées. La façon de faire peut énormément varier selon le type de projet, la méthodologie et l'organisation des équipes.
Après le web c'est plein de branle couilles, de PHP warriors et de serial cut&pasters. Mais c'est pas en leur foutant une machine pourrie que tu vas en faire des bons ingénieurs…
[^] # Re: Chaudière à uranium et caféine
Posté par ckyl . En réponse à la dépêche Mod_pagespeed : un accélérateur de pages Web. Évalué à 4.
Mouais. La plus grosse différence entre les environnements de dev et la prod c'est que les devs bossent à latence 0 et ça ça change tout. Limiter les ressources sur les machines des devs ca ne sert vraiment pas à grand chose. On passe par des chemins d'exécutions qui n'ont rien à voir, des configurations très différentes et une charge ridicule. Faut juste faire les tests de charge sur des machines réalistes avec des scénarios réalistes.
[^] # Re: Chaudière à uranium et caféine
Posté par ckyl . En réponse à la dépêche Mod_pagespeed : un accélérateur de pages Web. Évalué à 4.
En même temps si ça fait le boulot… C'est comme tout, il faut analyser la chose pour voir ce que ça fait exactement et comment, puis décider de ce qu'on peut lui déléguer ou non. Dans l'évolution de toute technologie on commence par devoir tout maîtriser puis laisser petit à petit l’environnement certains tâches qu'il peut faire aussi bien que nous mais plus rapidement et pour moins cher.