À l'époque où je cherchais, j'avais vu des bureaux mécaniques chez Ergotron, comme ce modèle là. Par contre, pour se le procurer en france, c'est une autre paire de manche.
Du coup, j'ai opté pour un électrique, de chez MDD (Ergonomic master: pas de lien, car leur site est cassé en ce moment). On en trouve chez des revendeurs en France. J'en ai eu pour 900-1000 Euros HT (payé par ma boite). Et j'ai rajouté un range-cable ikea.
C'est plus cher qu'IKEA, mais : il ne bouge pas et le plateau est de très bonne facture. Bref, à priori donc de meilleure qualité. Je n'ai pas eu à me plaindre de la motorisation.
Cependant, il y a les mêmes reproches :
boutons pas très ergonomiques
à peu près le même temps de changement de position
les colonnes télescopiques "inversées", et il m'est moi aussi arrivé de coincer la poubelle :-)
Mais je dirais qu'à part les boutons, les reproches sont inhérents à ce type de bureau.
Si un jour je dois changer, je prendrais mon courage à deux mains pour me procurer un bureau mécanique.
En ce qui concerne l'utilisation, je confirme que rester debout trop longtemps, c'est pas terrible. L'immobilisme trop long debout me créer des douleurs dans le dos. Du coup j'essaye de bouger un peu mais pas évident. Je pense moi aussi à essayer le tapis de marche :-)
Cependant, je ne reviendrais pas sur le bureau uniquement "assis". C'est agréable de pouvoir bosser debout de temps en temps, en particulier dans les moments de réflexion. Dans ces moments là, je peux "tourner en rond" debout dans la pièce, et de temps en temps noter/chercher des trucs sur mon ordi ou un calepin sans avoir à me pencher ou me rassoir. Idem aussi quand je fais des allers-retours entre mon bureau et mon tableau blanc. Pratique aussi quand je classe/range/cherche de la paperasse avec les aller-retour entre le bureau et l'armoire.
Toutefois, le bureau assis-debout n'est pas suffisant pour l'entretien du corps : il faut se forcer à bouger dans la journée (marche, vélo etc). Du coup, au lieu d'utiliser la voiture pour aller chercher le pain ou aller à la poste, j'y vais maintenant à pied :-)
J'ai un synology. C'est bien du linux mais ça ne repose pas sur une distro classique. On peut y accéder en SSH, et l’environnement c'est busybox.
Comme le QNAP, on a une belle interface web pour le gérer.
Par contre, le processeur est vraiment faiblard (j'ai un DS212+). ça va pour la plupart des tâches, mais pour certaines, pas du tout. Par exemple, il indexes les photos et vidéos pour qu'on puisse y accéder par dnla ou une appli web embarquée, et génère en même temps des miniatures : ça prend une éternité (plusieurs jours pour quelques giga de photos). Insupportable. Du coup je génère les miniatures sur mon desktop (avec les bons noms et repertoires), et je les balance sur le nas en même temps que les ladites photos. Il a ainsi juste l'indexation à faire (il liste les photos dans une base postgresql, pas sûr que ce soit le plus efficace d'ailleurs).
On peut lancer un script, et c'est à peu près tout
Et c'est déjà énorme !
En fait, je trouve cela très sympa au final : c'est hyper souple, tu fais ce que tu veux. Tout ce que tu veux. C'est pas comme les trucs immonde comme jenkins où tout est finalement limité par ce que propose les plugins. Les plugins, soit ce sont des usines à gaz parce qu'ils veulent prendre en charge tous les paramètres de l'outil qu'ils proposent de manipuler, soit il n'y a pas tous les paramètres, et alors un jour on se retrouve coincé.
Au début j'étais un peu comme toi déçu, "ça ne fait que ça". Mais à l'usage en fait c'est très bien. j'utilise aussi dans le meme genre strider-cd. On peut se développer des plugins pour faciliter les choses si on en a marre de taper toujours les meme scripts.
De plus, l’accès au répo n’est pas nécessaire pour le rendre libre, un tgz avec les sources peut suffire, même si ce n’est pas pratique.
Ce n'est pas pratique si il espère recevoir des contributions. Mais à priori, ce n'est pas son but premier. Donc qu'il garde son dépôt git, et qu'il mette en téléchargement un tgz. Github n'est pas nécessaire.
Maintenant, si il accepte les contributions, alors là oui, un miroir sur github est nécessaire. ça sera plus simple pour les contributeurs et pour lui. (perso, les patchs par mail, je ne suis pas fan :-) )
Pour github ou autre : (…)
Autre solution que j'ai adopté : github comme repo principal + strider-cd sur mon serveur. On enregistre strider-cd sur github, on configure strider-cd pour qu'il lance les builds et tout le toutim (bref, le script qu'il a indiqué sur le hook du commit dans son dépot actuel), et il a ses builds et tests à chaque commit.
rien n'empêchera de faire un Firefox Desktop avec browser.html ou équivalent.
J'ai bon ?
tout à fait.
Qui plus est, si ces API sont standardisées (ce qui est le but ultime de mozilla), que le format "webapp" est lui aussi standardisé, et tout ça implémenté dans d'autres moteurs, on pourrait imaginer à terme lancer notre browser.html avec blink ou webkit par exemple.
Mais il y a encore beaucoup de chemin à parcourir, malgré que l'on puisse dés aujourd'hui lancer une webapp indifféremment avec Firefox desktop, Firefox pour Android ou encore FirefoxOS (sauf si ladite appli utilise les api de téléphonie par exemple : ça va moins bien fonctionner sur le desktop :-)).
Grâce à cette discussion je viens de découvrir SlimerJS. Je ne savais même pas que ce genre d'outil existait, faudra que je test à l'occasion pour les units test dans au moins 1 projet. Donc encore une fois merci
ça me semblerai être un sacré échec de ne pas pouvoir utiliser HTML5 pour implémenter les quelques controls/boite de dialogues de Firefox en HTML/JS/CSS.
Ce n'est pas implémenter des boites de dialogues qui posent problème, c'est tout ce qu'il y a dans un navigateur.
browser.html, ce n'est pas un fichier html que l'on va mettre dans firefox en remplacement de XUL, et qui va tourner en mode privilégié comme le XUL. browser.html est une webapp. qui tourne donc dans une sandbox.
Du coup, comment dans l'interface on affiche par exemple l'historique de navigation (pour le gestionnaire de l'historique) ? comment accéder à la liste des mots de passe (pour le dialog de gestion des mots de passe) ? Comment modifier les préférences (pour une bonne partie des paramètres de la boite de préférences) ? Il y a aussi la gestion des "commandes" de l'interface, la gestion du copier coller, la gestion de la fenetre etc…
Bref, un navigateur, ce n'est pas juste afficher une page web, c'est aussi est surtout pouvoir gérer plein de truc autour. Et pour cela, il faut utiliser des API interne. Chose facile quand on est en XUL, parce que le code JS/XUL de Firefox (et celui des extensions XUL) tourne en mode privilégié (le mode chrome), et donc on peut appeler n'importe quel composant interne XPCOM.
Et le souci ici est que l'interface de browser.html, comme toutes les webapps, comme toutes les applis de FirefoxOS, tournent dans une sandbox. Pas d’accès direct à ces composants internes.
Il faut donc exposer, dans le contexte HTML, des API qui permettent de pouvoir faire ce qu'on pouvait faire en mode chrome.
Ces API étant souvent "sensibles", il y a un système de permissions.
Un exemple d'API, c'est l'api de navigation. Ça l'air con de gérer des onglets et la navigation : suffit de gérer des iframes, et dans chaque iframe, tu charges un site. Oui mais pas seulement. Comment surveiller l'état du chargement d'une iframe, afin de pouvoir afficher un throbber dans la barre d'url ? Comment stopper le chargement d'une iframe ? comment detecter justement que l'iframe démarre le chargement d'une nouvelle page, pour mettre à jour l'url dans la barre d'url ? Comment récupérer les informations sur le certificat SSL du site chargé afin de pouvoir les afficher quand on clique sur le cadenas ? etc etc etc… En mode chrome, aucun souci. Mais quand tu es dans une page HTML qui n'a pas les privilèges chrome, t'es à poil. En html standard, tu n'as pas d'API pour tout ça.
Il faut donc développer ces API (qui, techniquement, à leur tour, appellerons les apis interne de gecko). Tu as un début avec la browser API, mais ce n'est pas suffisant. Il faut une API pour accéder au contenu de l'historique complet, une API pour accéder aux certificats, et des centaines d'autres API. Et créer/gérer les permissions qui vont avec.
Bref, il y a encore beaucoup, beaucoup de boulot. C'est d'ailleurs la raison pour laquelle le "navigateur" dans FirefoxOS est encore si pauvre en fonctionnalité.
D'ailleurs, tu remarqueras que pour faire les trucs de bases (copy/paste/undo/redo) de browser.html, tout ça est géré dans un fichier XUL lancé en mode chrome.
Note: il y a eu le même problème pour les extensions de type jetpack (non xul donc), qui tournent dans une sandbox JS. Il a fallu exposer dans cette sandbox un certain nombre d'API pour accéder aux API internes de Gecko. Et implémenter tout ça ne s'est pas fait en un jour (raison pour laquelle on a encore accès à un module "chrome" pour accéder directement aux composants internes).
les anti-virus décents ont un impact négligeable sur un desktop
Autant les autres points je suis à peu près d'accord (et encore, ça dépend ce qu'on fait exactement), autant pour les antivirus, non.
Parce que quand il faut que tu compiles, sur une machine un peu juste au niveau puissance, et qu'en plus tu ne peux pas toucher à l'antivirus (le mettre en pause par exemple), c'est juste horrible, j'en ai fait maintes fois l’expérience. Le pire étant l'antivirus programmé par les admin pour faire un scan complet en plein milieu de la journée (vécu) : la machine (assez vieille) freezait quasiement.
j'ai du mal à comprendre pourquoi ces décideurs ne comprendraient pas ta demande.
Tu dois faire un boulot. Il te faut un outil ayant certaines caractéristiques, sinon tu ne peux pas réaliser le boulot demandé.
Personnellement, je ne sais pas ce que je pourrais ajouter de plus comme argument. Pas de matos ? pas de développement.
Ah tiens, si, j'ai une idée. Demande à ces décideurs, ce qu'ils penseraient si on leur filait un nokia 3310 plutôt que leur iphone6, ou un ordi portable sans marque premier prix vieux de 10 ans pour réaliser leur powerpoint ou tableaux excel…
Sinon, il y a un contrat. Puisque le matériel est fourni par le client, n'y a-t-il pas une clause d'obligation de moyen par le client ?
Je ne pense pas que ce soit une bonne idée pour Mozilla de les inclure de base… (même si je les utilise tous les deux)
Bon, on pourrait imaginer qu'ils développent ou choisissent une solution plus éthique, mais cela pose d'autres problèmes :
il faut maintenir des filtres : ça prend beaucoup de temps à gérer
j'imagine que cela est interdit dans les contrats commerciaux qu'ils ont avec les moteurs de recherche, en autre Google, qui sont aussi des régies publicitaires…
Pour Firefox, mon raisonnement est le même : on a un moteur html qui est lancé, pourquoi ne pas l'utiliser partout.
C'est exactement l'idée qu'ont eu les développeurs quand ils ont crée Gecko : utiliser le moteur de rendu pour l'interface utilisateur (1998). D'où le XUL (un langage XML + js pour le comportement + CSS pour l'apparence). Je pense qu'à l'époque, ils n'ont pas utilisé le HTML parce qu'il était très basique, cela aurait nécessité de trop gros changement dans le HTML et le CSS (trop de balises et styles propriétaires) : d'où un nouveau langage. De plus le XUL a des fonctionnalités très spécifiques comme les overlays, l'usage des DTD pour les traductions et bien d'autres choses.
Bref, on a un moteur qui sait prendre n'importe quel langage XML et HTML, et sait l'afficher en le stylant en CSS.
browser.html, c'est très bien, mais ils manquent encore des choses en HTML pour faire tout ce qu'on peut faire en XUL, pour qu'il remplace ce bon cher browser.xul.
Et puis abandonner XUL, cela voudrait dire abandonner une grosse majorité des extensions… XUL va disparaitre, mais c'est pas pour demain. Il y a énormément de boulot.
Ne serait-il pas plus pertinent de ne plus avoir de Xul/Gtk3/Gtk2 ni Xul/Cocoa ni Xul/(Windows je ne sais quoi), en utilisant une interface web dans gecko lui même, par exemple : browser.html
Euh… Non…
Gtk ne sert pas qu'au XUL. Je dirais même, pas trop à XUL. Conçernant XUL, GTK sert juste à savoir des infos comme les couleurs systèmes, accéder aux fontes système etc. XUL, ce n'est que du HTML++ : tout est stylé en CSS. Il est vrai aussi que XUL s'appuie sur le toolkit (gtk, cocoa ou Windows) pour dessiner les boutons et quelques autres trucs d'interfaces. Et tu sais quoi ? c'est dessiné en indiquant la propriété CSS appearance. Qui sert aussi en HTML puisque cette propriété était prévu dans la spec css3-ui et reportée dans css4, mais cela n’empêche pas qu'elle soit implémentée dans Firefox et Webkit.
La présence de GTK/Cairo/Windows est surtout là pour gérer les fenêtres, ouvrir les boites de dialogues de fichier, d'impression etc du système, accéder au presse papier et de beaucoup d'autres choses.
Bref, XUL ou HTML, un navigateur a besoin d'un toolkit comme gtk et autre, en plus d'une lib purement graphique.
Mais vu que je passe beaucoup de temps à coder et que je n'ai pas publié grand chose, j'aurais peut être pu passer ce temps à étudier Python plutôt que m'énerver contre la "mauvaise" modernisation de PHP :)
<Ironie> Ouuuuh là!! Attention, tu va être TRÈS décu. en effet, beaucoup de lib et d'applis s'installe avec PIP, qui est très similaire à Composer. Tu ne vas pas pouvoir faire totalement du dev à contre courant de ce que l'écosystème propose :-p </Ironie>
Oui, mais c'est encore plus simple et rapide d'extraire une archive.
en tant que développeur. Non. Pas du tout. Puisque j'ai même pas à connaitre l'url. Juste le nom du paquet. Une ligne dans le json (nom/version), composer install, et c'est terminé. Je veux mettre à jour ? je change la version dans le json, composer update. c'est terminé.
Alors qu'avec une archive : je dois aller la récupérer sur le site du projet, la dézipper dans mon projet, chercher à savoir comment inclure la lib, ou instancier son autoloader, et donc faire un include (voire plus) quelque part dans mon code. Ensuite, je veux mettre à jour (souvent plusieurs mois après) : faut que je retourne sur le site (dont j'ai oublié le lien, hop, détour par google), retélécharger à la mimine, dézipper les fichiers, ajouter les nouveaux fichiers dans le subversion/git, et supprimer les fichiers qui n'existent plus dans la nouvelle version (ce qui peut être fastidieux, et je parles en connaissance de cause), vérifier dans la doc que l'autoloading ou l'inclusion se fait toujours pareil…
Bah désolé, non, avec Composer, je n'ai pas toutes ces emmerdes, puisque Composer me télécharge tout ça automatiquement, qu'il m'évite à un inclure dans mon dépôt git ces libs externes, et parce que l'inclusion/autoloading, c'est Composer qui fait tout ça pour moi.
Je rajoute l'argument sécurité: si l'URL du dépôt de ton framework est comprise et que le dev qui utilise composer ne vérifie pas ce que composer télécharge…
Parce que le site où tu télécharge ton zip, il ne peut pas être compromis ? tu vérifie tout les zip des libs que tu télécharges ? cela voudrait dire que tu vérifie le contenu de chaque fichier ? et pourquoi alors tu ne pourrais pas le faire dans les sources posées dans le vendor/ par Composer ?
L'argument de sécurité est nul ici.
de plus en plus d'applications complètes utilisent composer comme méthode d'installation par défaut (Magento par exemple)
Perso je trouve ça bête pour un utilisateur final. Mais Magento n'est pas un bon exemple pour ton argumentaire. Le lien que tu montres, c'est la doc pour les développeurs (c'est marqué sur la page). Donc oui, là, utiliser Composer a un sens. Puisque si tu es développeur, cela veut dire que tu vas personnaliser Magento, lui rajouter du code pour des traitements metiers, des plugins ou que sais-je, et donc probablement installer d'autres lib (en utilisant Composer ou pas).
Pour les utilisateurs finaux, il faut aller voir sur le site pour les utilisateurs. Et qu'y trouve-t-on ? Oh, miracle, des tar.gz prêts à l'emploi ! ;-)
La majorité des paquets composer ne sont pas des applications complètes mais des librairies. A mon sens c'est une grosse différence.
Tu parlais de projets libre. Alors, à moins que pour toi une lib libre n'est pas un projet libre, je ne vois pas de différence.
Ce que je veux dire c'est que quand on développe une application à destination du "grand public", on cherche à lui donner une identité. Si on se contente d'un bootstrap à peine modifié, ….
Tu passes de PHP à Bootstrap, du coq à l'âne, donc des problématiques différentes. J'avoue que ton discours est très difficile à suivre.
Si les libs étaient proposées avec leur propre auto-loader (ce que fait, une fois encore, PHPUnit, PHPMailer, Smarty, etc.), il n'y aurait pas besoin de faire ça à la main.
Oui donc, au final, dans un projet, si tu utilises 25 libs, tu as alors 25 autoloaders, qui font quasiment la même chose. Bonjour les perfs. Avec Composer : on peut avoir un seul autoloader, en particulier si on utilise les namespaces (il est possible de lui indiquer des autoloaders spécifiques si nécessaire, par exemple ceux des libs ayant un autoloader spécifique).
C'est à la librairie de dire comme se charger, on n'a pas à le "deviner" ou le supposer.
Justement, avec Composer, on a encore moins à s'en charger, puisqu'il y a au final 0 include à faire après avoir installé une lib. Alors que, pour une lib "non composerifiée", il faut que tu saches quel fichier inclure (celui qui fait tout les includes de la lib ou qui déclare l'autoloader de la lib).
Moi, ce que je vois avec composer, c'est que quand tu code une appli libre, tu cherche à simplifier au maximum l'installation.
Moi quand je code, je veux faire les choses vite et bien, parce que ce qui m’intéresse, c'est avant tout de pouvoir répondre à un besoin. Alors si l'installation d'une lib est simplifiée, si les développeurs peuvent installer mon framework en déclarant une petite dépendance et en tapant une seule ligne de commande, ça me va.
Je suis désolé mais non, pour un débutant qui veut utiliser son application, ce n'est pas plus simple de faire (…)
que d'extraire une archive
Tu parles d'un utilisateur, ou d'un développeur ? Parce que si c'est pour fournir une application finale (un truc comme wordpress ou phpbb) destinée aux utilisateurs, oui faut être con pour proposer ce genre de chose (encore que, si Composer est installé d'office par les distros, ça peut avoir du sens). Et si je ne me trompe pas, ce genre de projet proposent en général un zip pour les utilisateurs, comportant toutes les dépendances, à déposer quelque part, prêt à être utilisé.
Pour les développeurs de l'application par contre, non, Composer facilite le développement, les mises à jours des dépendances, l'installation du projet etc… Et donc Composer convient très bien au développement.
Faut pas confondre développement et utilisation. Développeur et utilisateurs.
En ce qui concerne debian et cakephp, j'ai bien l'impression que ce que tu racontes n'a rien à voir avec Composer…
composer est bien pour gérer les dépendances d'un projet pro, statique, où personne ne va mettre son nez dedans, mais pour un projet Libre, je pense que ce n'est pas une bonne solution.
Désolé, mais tu me fais bien rire là :-) La majorité des packages installables par Composer sont des projets libres. Donc pour ces projets, ce n'est pas la solution ??? Pourquoi ils sont dans Composer alors ? Pourquoi c'est autant utilisés ?
Quand on code une appli libre, on n'industrialise pas.
Gniiii ??? c'est quoi cette histoire ? Pourquoi il ne faudrait pas "industrialiser" ?
Parce qu'on code une appli libre, il ne faudrait pas utiliser les outils que l'on a à notre disposition pour développer, déployer, tester et tout faire à la mimine ou rien faire ???
Bah désolé, une partie de mes projets libres, je les développe sur mon temps libre (qui se restreint de plus en plus). Tout outil qui pourrait me faire gagner du temps, qui me permettrait d'être plus productif, je les utilises.
Et c'est d'autant plus intéressant que j'en profite pour découvrir des nouveaux outils ou libs, qui me permettent ensuite au niveau professionnel de monter en compétence, d'être plus productif (et donc éventuellement d'avoir plus de temps pour dev les projets libres).
Si le gestionnaire de dépendance était partie intégrante de PHP, les choses seraient différentes, mais là c'est un projet lambda. Et forcer à son utilisation est contraire à la philosophie du Libre.
J'hallucine là. Tu trolles là en fait hein ? c'est ça ?
Je vais t'apprendre un truc : n'importe quel lib proposée par Composer, tu peux l'utiliser sans Composer. Suffit juste que tu ailles chercher toi même les dépendances, et te faire un autoloader (ce qui est une perte de temps à mon avis).
Les traits sont un paliatif au fait que PHP ne supporte pas l'héritage multiple. Je trouve leur syntaxe confuse:
Non les traits n'est pas un paliatif. Ça n'a d'ailleurs rien à voir avec l'héritage multiple, et ça ne cherche pas à remplacer l'héritage multiple (qui pose lui même bien des problèmes dans d'autres langages).
Je trouve dommage que le nom du site fasse référence à la piraterie.
Les gens vont assimiler linux = warez. C'est con.
PS: ouai, ok, à priori tu milites pour le parti pirate, mais franchement sur le site, c'est pas évident à comprendre pourquoi ce mot pirate. Bref, comme pour le parti Pirate, le nom va à l'encontre des idées au final, ce qui rend le truc pas crédible.
De façon assez étrange, ni Smarty, ni Redbean ne mentionnent composer dans leur documentation, et PHPMailer s'en passe parfaitement.
Parce que peut-être les développeurs de ces libs ne s'y sont pas vraiment intéressé ou ne veulent pas, ou sont réfractaires à certains changement ? D'ailleurs Redbean le dit bien : le gars est "conservateur".
Cela ne veut pas dire que Composer c'est de la merde.
Et tu noteras que tu cites quand même des projets vraiment vieux (voir à peine maintenu comme PHPMailer). Lourd passif donc.
M'enfin bon, même si des libs comme celle-là ne sont pas fournie en paquet Composer, c'est juste 3 lignes de code supplémentaires à rajouter dans ton composer.json pour les intégrer dans ton projet. Pas la mort quoi.
comment avoir confiance dans une librairie dont l'auteur ne prend pas la peine de faire un site sans tomber dans le piège oisif de bootstrap
J'ai l'impression que tu ne maintiens pas de projet public pour dire ça, ou alors tu es super compétent en design web et c'est super facile pour toi de pondre un design html/css.
J'ai plusieurs projets open source en PHP que je développe et maintien depuis des années. J'ai beau être compétent techniquement en HTML et CSS, je peux te dire une chose : ça me fais chier grave de faire les sites web de mes projets. Parce que je suis incompétent en design web et du coup, quand il faut que je refasse l'un deux, j'y passe des jours pour que ça ressemble à quelque chose. Ce temps, je préfère le passer à développer la lib. Donc je comprend très bien ceux qui choisissent bootstrap ou autre trucs "pour se faciliter la vie".
ni Smarty n'utilisent bootstrap sur leur site.
Ça c'est normal : le site de Smarty n'a pas bougé depuis 10 ans. Idem pour PHPMailer. Ils sont probablement comme moi : ils préfèrent passer du temps sur leur lib que sur le design de leur site.
Maintenant, utiliser bootstrap, ça a ses avantages : c'est responsive nativement, ça offre d’amblé un design "moderne" etc…
je ne comprends pas comment il est possible que de telles librairies ou outils puissent avoir une telle cote de popularité.
parce que j'ai l'impression que tu n'as pas trop en tête les avantages qu'ils offrent…
Aujourd'hui, tout le monde boude PEAR,
Je te rassures, même avant tout le monde boudait Pear. Quelle a été la proportion de lib et de projets qui proposait un paquet Pear ? 0,5% ? 1%? Franchement on n'y trouvait pas grand chose.
Et maintenant avec Composer ? 70%, 80%, 90% ? Le nombre de projets dispo via Composer est sans commune mesure avec Pear.
Et si Composer a un tel succès, c'est bien parce qu'il offre quelque chose de mieux non ?
Perso je n'ai jamais aimé Pear.
Déjà, c'est un truc hyper fermé : il faut que ton projet respecte certaines règles, notamment le coding style (que je trouve horrible). Ensuite, il faut qu'il soit accepté par les gens qui gère Pear. Tu ne peux pas avoir de doublons en terme de fonctionnalité avec une autre lib. Au final, Pear ne propose pas grand chose. Ou alors des usines à gaz. Interroge toi par exemple pourquoi tu as choisi PHPMailer plutôt que leur lib de mail.
Ensuite, sur le serveur (en particulier avec Debian), ton depôt PEAR est forcément partagé par tous tes projets. Au final, tu te retrouve coincé : tu ne peux pas mettre à jour au risque de casser tes vieux projets, et donc tu ne peux pas profiter des dernières versions pour des nouveaux projets. Et même si tu veux mettre à jour, c'est la galère avec debian, on ne sait jamais ce qu'il faut faire vraiment (y a toujours eu des trucs qui cassaient chez moi). Ne serait-ce que pour mettre à jour PHPUnit avec Pear. ça a toujours été la galère (à cause principalement qu'il faille faire ça en sudo, qu'il faille modifier le include_path dans la conf PHP etc).
Alors qu'avec Composer, tu as un dépôt par projet, chaque projet évolue comme il veut, utilise les paquets qu'il veut. PHPUnit et les autres paquetes s'installent en deux coup de cuillère à pot. Pas besoin de droits spéciaux sur le système pour les installer. Peu importe au final le système : ton projet reste indépendant.
M'enfin comme tu l'as dit toi même Pear c'est plus un Framework qu'un gestionnaire de dépendance. Donc au final, peu de rapport avec Composer.
Les gros avantages de Composer, c'est qu'il fait un seul truc et le fait bien : installer des paquets et gérer les dépendances. Un apt pour PHP.
L'autre gros avantage de Composer : il génère un autoloader. Adieu tous les includes dans tout les sens pour charger une lib ! Et si en plus les lib utilisent les namespaces (en respectant PSR-0 ou PSR-4), l'autoloader est beaucoup plus efficace.
À l'usage on se rend compte que ça apporte plus de souplesse, moins de tracas, et plus de perf (pas de chargement de classes non utilisées).
Le pire, c'est que toutes ces libs modernes suivent les recommandations PSR, donc devraient être facilement utilisables partout quelle que soit la configuration du serveur sur lequel elles sont installées.
Ah non pas du tout ! Les PSR ne servent pas à faire en sorte que ça fonctionne quelle que soit la conf serveur. Je ne sais pas où tu as lu ça. Pour le moment, ils ont des recommandations pour le nommage des classes (PSR-0 et PSR-4), afin de faciliter le développement des autoloaders (que l'on n'a plus à développer si on utilise Composer), des recommandations sur le coding style (PSR-1 et PSR-2), et une recommandation sur l'interface d'un objet qui fait du log. Et ce qui est en discussion actuellement ce sont d'autres interfaces pour d'autres types d'objets courant (gestionnaire de cache, lib http…).
(donc non, ça ne servira pas qu'à Composer).
Bref, ce sont des choses pour améliorer l'interopérabilité entre les frameworks. Rien à voir avec la conf des serveurs.
Et puis ce ne sont que des recommandations. Pas obligé de les suivre.
composer qui a, par ailleurs, la fâcheuse tendance à installer tout un tas de truc que je n'ai jamais demandé et qui n'existe pas dans les archives
Composer installe ce que les paquets ont besoin, pas plus, pas moins. Si un paquet a une dépendance envers un autre paquet et qu'il n'utilise pas, la faute est au développeur, pas à Composer. Mauvais paquet, changer paquet. (ça tombe bien, contrairement à Pear, le choix est très vaste).
phpass - génération de hash sécurisés pour les mots de passe, en l'absence de blowfish
Avec la nouvelle api password de PHP, cette lib est devenu inutile et obsolète (voir dangereuse, vu qu'elle n'est plus maintenue ?).
leur usage abusif des namespaces
Les namespaces, c'est bon, mangez-en : ça évite les collisions de classes entre libs, ça facilite l'autoloading, ça permet une programmation moderne, ça force (un peu) à mieux organiser son code.
Je suis en train de "namespacer" mon framework, ça fait beaucoup de bien au final.
Pour finir, Composer, on peut s'en passer, mais c'est devenu la norme maintenant pour distribuer et installer des libs en PHP. L'ignorer ou le dénigrer n'aidera pas dans tes projets présent et futurs.
bah pour des utilisateurs qui veulent pas voir des noms pareils à chaque fois qu'ils ouvrent leur gestionnaire d'applis.
Oué, c'est un peu comme ces mecs qui font des caricatures
Non, ce n'est pas comme les caricatures. Si on prend l'exemple de celles de Charlie Hebdo : si tu n'aimes pas, tu n'achètes pas le journal. Contrairement à ici où c'est imposé. On peut toujours changer de système d'exploitation, mais c'est plus compliqué que d’arrêter d'acheter un journal.
Franchement, ils se prennent pour qui?
pour des gens qui donnent leur avis ? ils ont ce droit il me semble, non ?
sans même profiter de l'architecture de plug-ins intégrée depuis les débuts?
à priori, tu ne sembles pas comprendre comment fonctionne les plugins (aka les trucs qui se charges avec une balise object en html). Il ne t'ai pas venu à l'idée que si ils n'ont pas utilisé cela, c'est que c'était inadapté ? (les plugins sont des boites noires sur lesquels le navigateur n'a AUCUN contrôle, y compris graphique, donc intégration très limités dans les pages web).
qui mets en avant la puissance de son architecture de plug-ins
Là tu parles des extensions XUL, pas des plugins. Un truc totalement différent.
Si au lieu d'ajouter les fonctionnalités en dur, ils ajoutaient des plugins qui sont installés par défaut, ça me semblerait vachement plus logique, et ça permettrait de réduire la complexité de la compilation et du source
Bah oui tient bien sûr ! Pourquoi ils n'y ont pas pensé ?? Franchement, ces développeurs, c'est tous des incompétents !
C'est vrai quoi, n'importe quel libs peut "se pluginiser" !
Non, sérieusement, tu es développeur ?
Mon opinion, qui peut être mauvaise ok, c'est que quand on mets des options pour désactiver des fonctionnalités, il faudrait peut-être au moins essayer de compiler en les activant.
Tu as vu le nombre d'options ? Tu crois que Mozilla a les ressources nécessaires pour tester tous les cas de figure ?
Sans compter que certaines options sont des contributions externes pour des besoins spécifiques, donc non maintenue par Mozilla. D'autres sont des options qui sont là parce qu'elles étaient nécessaires lors du développement de telle ou telle fonctionnalité, puis oubliée par la suite. Enfin il peut aussi y avoir des bugs. Tu as indiqués ces bugs ? Tu es allé demander une solution ?
Pourquoi ne pas avoir fait une transition franche, pourquoi chercher à réinventer la roue (les alternatives aux autotools c'est pas ce qui manque)?
Peut-être parce que faire une transition franche de cette sorte, ça se fait pas en 2 secondes, que c'est très compliqué pour un projet de cet envergure. et que ça pourrait bloquer le développement d'autres choses plus prioritaires pendant un certain temps ? Et puis de toute façon, pourquoi tu demandes ça ici ? tu ne trouves pas que tu devrais plutôt demander ça directement à ceux qui le développent ?
# Mécanique ça existe
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Retour d'expérience : bureau assis/debout. Évalué à 7.
À l'époque où je cherchais, j'avais vu des bureaux mécaniques chez Ergotron, comme ce modèle là. Par contre, pour se le procurer en france, c'est une autre paire de manche.
Du coup, j'ai opté pour un électrique, de chez MDD (Ergonomic master: pas de lien, car leur site est cassé en ce moment). On en trouve chez des revendeurs en France. J'en ai eu pour 900-1000 Euros HT (payé par ma boite). Et j'ai rajouté un range-cable ikea.
C'est plus cher qu'IKEA, mais : il ne bouge pas et le plateau est de très bonne facture. Bref, à priori donc de meilleure qualité. Je n'ai pas eu à me plaindre de la motorisation.
Cependant, il y a les mêmes reproches :
Mais je dirais qu'à part les boutons, les reproches sont inhérents à ce type de bureau.
Si un jour je dois changer, je prendrais mon courage à deux mains pour me procurer un bureau mécanique.
En ce qui concerne l'utilisation, je confirme que rester debout trop longtemps, c'est pas terrible. L'immobilisme trop long debout me créer des douleurs dans le dos. Du coup j'essaye de bouger un peu mais pas évident. Je pense moi aussi à essayer le tapis de marche :-)
Cependant, je ne reviendrais pas sur le bureau uniquement "assis". C'est agréable de pouvoir bosser debout de temps en temps, en particulier dans les moments de réflexion. Dans ces moments là, je peux "tourner en rond" debout dans la pièce, et de temps en temps noter/chercher des trucs sur mon ordi ou un calepin sans avoir à me pencher ou me rassoir. Idem aussi quand je fais des allers-retours entre mon bureau et mon tableau blanc. Pratique aussi quand je classe/range/cherche de la paperasse avec les aller-retour entre le bureau et l'armoire.
Toutefois, le bureau assis-debout n'est pas suffisant pour l'entretien du corps : il faut se forcer à bouger dans la journée (marche, vélo etc). Du coup, au lieu d'utiliser la voiture pour aller chercher le pain ou aller à la poste, j'y vais maintenant à pied :-)
[^] # Re: et les nas commerciaux ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Actualités NAS. Évalué à 2.
J'ai un synology. C'est bien du linux mais ça ne repose pas sur une distro classique. On peut y accéder en SSH, et l’environnement c'est busybox.
Comme le QNAP, on a une belle interface web pour le gérer.
Par contre, le processeur est vraiment faiblard (j'ai un DS212+). ça va pour la plupart des tâches, mais pour certaines, pas du tout. Par exemple, il indexes les photos et vidéos pour qu'on puisse y accéder par dnla ou une appli web embarquée, et génère en même temps des miniatures : ça prend une éternité (plusieurs jours pour quelques giga de photos). Insupportable. Du coup je génère les miniatures sur mon desktop (avec les bons noms et repertoires), et je les balance sur le nas en même temps que les ladites photos. Il a ainsi juste l'indexation à faire (il liste les photos dans une base postgresql, pas sûr que ce soit le plus efficace d'ailleurs).
Sinon dans l'ensemble ça va j'en suis content.
[^] # Re: CDN ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Autohébergement : mon retour d'expérience acte 2. Évalué à 0.
Oui, c'est un peu de l'hébergement distribué en fin de compte.
Un peu la philosophie du net quoi…
[^] # Re: gitlab-ci
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Un bond en avant pour Gitlab.com. Évalué à 2.
Et c'est déjà énorme !
En fait, je trouve cela très sympa au final : c'est hyper souple, tu fais ce que tu veux. Tout ce que tu veux. C'est pas comme les trucs immonde comme jenkins où tout est finalement limité par ce que propose les plugins. Les plugins, soit ce sont des usines à gaz parce qu'ils veulent prendre en charge tous les paramètres de l'outil qu'ils proposent de manipuler, soit il n'y a pas tous les paramètres, et alors un jour on se retrouve coincé.
Au début j'étais un peu comme toi déçu, "ça ne fait que ça". Mais à l'usage en fait c'est très bien. j'utilise aussi dans le meme genre strider-cd. On peut se développer des plugins pour faciliter les choses si on en a marre de taper toujours les meme scripts.
[^] # Re: Du coup je passe en libre
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal [Trackgame] Jeu de course vectoriel au tour par tour. Évalué à 2.
Ce n'est pas pratique si il espère recevoir des contributions. Mais à priori, ce n'est pas son but premier. Donc qu'il garde son dépôt git, et qu'il mette en téléchargement un tgz. Github n'est pas nécessaire.
Maintenant, si il accepte les contributions, alors là oui, un miroir sur github est nécessaire. ça sera plus simple pour les contributeurs et pour lui. (perso, les patchs par mail, je ne suis pas fan :-) )
Autre solution que j'ai adopté : github comme repo principal + strider-cd sur mon serveur. On enregistre strider-cd sur github, on configure strider-cd pour qu'il lance les builds et tout le toutim (bref, le script qu'il a indiqué sur le hook du commit dans son dépot actuel), et il a ses builds et tests à chaque commit.
[^] # Re: Et quid du portage gtk3 ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Firefox 35 heures. Évalué à 4.
tout à fait.
Qui plus est, si ces API sont standardisées (ce qui est le but ultime de mozilla), que le format "webapp" est lui aussi standardisé, et tout ça implémenté dans d'autres moteurs, on pourrait imaginer à terme lancer notre browser.html avec blink ou webkit par exemple.
Mais il y a encore beaucoup de chemin à parcourir, malgré que l'on puisse dés aujourd'hui lancer une webapp indifféremment avec Firefox desktop, Firefox pour Android ou encore FirefoxOS (sauf si ladite appli utilise les api de téléphonie par exemple : ça va moins bien fonctionner sur le desktop :-)).
De rien :-)
[^] # Re: Et quid du portage gtk3 ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Firefox 35 heures. Évalué à 10.
Ce n'est pas implémenter des boites de dialogues qui posent problème, c'est tout ce qu'il y a dans un navigateur.
browser.html, ce n'est pas un fichier html que l'on va mettre dans firefox en remplacement de XUL, et qui va tourner en mode privilégié comme le XUL. browser.html est une webapp. qui tourne donc dans une sandbox.
Du coup, comment dans l'interface on affiche par exemple l'historique de navigation (pour le gestionnaire de l'historique) ? comment accéder à la liste des mots de passe (pour le dialog de gestion des mots de passe) ? Comment modifier les préférences (pour une bonne partie des paramètres de la boite de préférences) ? Il y a aussi la gestion des "commandes" de l'interface, la gestion du copier coller, la gestion de la fenetre etc…
Bref, un navigateur, ce n'est pas juste afficher une page web, c'est aussi est surtout pouvoir gérer plein de truc autour. Et pour cela, il faut utiliser des API interne. Chose facile quand on est en XUL, parce que le code JS/XUL de Firefox (et celui des extensions XUL) tourne en mode privilégié (le mode chrome), et donc on peut appeler n'importe quel composant interne XPCOM.
Et le souci ici est que l'interface de browser.html, comme toutes les webapps, comme toutes les applis de FirefoxOS, tournent dans une sandbox. Pas d’accès direct à ces composants internes.
Il faut donc exposer, dans le contexte HTML, des API qui permettent de pouvoir faire ce qu'on pouvait faire en mode chrome.
Ces API étant souvent "sensibles", il y a un système de permissions.
Un exemple d'API, c'est l'api de navigation. Ça l'air con de gérer des onglets et la navigation : suffit de gérer des iframes, et dans chaque iframe, tu charges un site. Oui mais pas seulement. Comment surveiller l'état du chargement d'une iframe, afin de pouvoir afficher un throbber dans la barre d'url ? Comment stopper le chargement d'une iframe ? comment detecter justement que l'iframe démarre le chargement d'une nouvelle page, pour mettre à jour l'url dans la barre d'url ? Comment récupérer les informations sur le certificat SSL du site chargé afin de pouvoir les afficher quand on clique sur le cadenas ? etc etc etc… En mode chrome, aucun souci. Mais quand tu es dans une page HTML qui n'a pas les privilèges chrome, t'es à poil. En html standard, tu n'as pas d'API pour tout ça.
Il faut donc développer ces API (qui, techniquement, à leur tour, appellerons les apis interne de gecko). Tu as un début avec la browser API, mais ce n'est pas suffisant. Il faut une API pour accéder au contenu de l'historique complet, une API pour accéder aux certificats, et des centaines d'autres API. Et créer/gérer les permissions qui vont avec.
Bref, il y a encore beaucoup, beaucoup de boulot. C'est d'ailleurs la raison pour laquelle le "navigateur" dans FirefoxOS est encore si pauvre en fonctionnalité.
D'ailleurs, tu remarqueras que pour faire les trucs de bases (copy/paste/undo/redo) de browser.html, tout ça est géré dans un fichier XUL lancé en mode chrome.
Note: il y a eu le même problème pour les extensions de type jetpack (non xul donc), qui tournent dans une sandbox JS. Il a fallu exposer dans cette sandbox un certain nombre d'API pour accéder aux API internes de Gecko. Et implémenter tout ça ne s'est pas fait en un jour (raison pour laquelle on a encore accès à un module "chrome" pour accéder directement aux composants internes).
[^] # Re: installer Linux nativement
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Besoin d'arguments pour obtenir une station de travail sous GNU/Linux ?. Évalué à 6.
Autant les autres points je suis à peu près d'accord (et encore, ça dépend ce qu'on fait exactement), autant pour les antivirus, non.
Parce que quand il faut que tu compiles, sur une machine un peu juste au niveau puissance, et qu'en plus tu ne peux pas toucher à l'antivirus (le mettre en pause par exemple), c'est juste horrible, j'en ai fait maintes fois l’expérience. Le pire étant l'antivirus programmé par les admin pour faire un scan complet en plein milieu de la journée (vécu) : la machine (assez vieille) freezait quasiement.
# comprend pas
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Besoin d'arguments pour obtenir une station de travail sous GNU/Linux ?. Évalué à 10.
j'ai du mal à comprendre pourquoi ces décideurs ne comprendraient pas ta demande.
Tu dois faire un boulot. Il te faut un outil ayant certaines caractéristiques, sinon tu ne peux pas réaliser le boulot demandé.
Personnellement, je ne sais pas ce que je pourrais ajouter de plus comme argument. Pas de matos ? pas de développement.
Ah tiens, si, j'ai une idée. Demande à ces décideurs, ce qu'ils penseraient si on leur filait un nokia 3310 plutôt que leur iphone6, ou un ordi portable sans marque premier prix vieux de 10 ans pour réaliser leur powerpoint ou tableaux excel…
Sinon, il y a un contrat. Puisque le matériel est fourni par le client, n'y a-t-il pas une clause d'obligation de moyen par le client ?
[^] # Re: Privacy for you™
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Firefox 35 heures. Évalué à 3.
Ghostery ? le truc qui, si tu fais pas gaffe, envoi tout ce qu'il bloque à la société qui le développe, pour ensuite… revendre ces données aux sociétés de pub/tracker &co ?
Adblock+, qui a lui aussi un drôle business model ?
Je ne pense pas que ce soit une bonne idée pour Mozilla de les inclure de base… (même si je les utilise tous les deux)
Bon, on pourrait imaginer qu'ils développent ou choisissent une solution plus éthique, mais cela pose d'autres problèmes :
[^] # Re: Et quid du portage gtk3 ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Firefox 35 heures. Évalué à 5.
C'est exactement l'idée qu'ont eu les développeurs quand ils ont crée Gecko : utiliser le moteur de rendu pour l'interface utilisateur (1998). D'où le XUL (un langage XML + js pour le comportement + CSS pour l'apparence). Je pense qu'à l'époque, ils n'ont pas utilisé le HTML parce qu'il était très basique, cela aurait nécessité de trop gros changement dans le HTML et le CSS (trop de balises et styles propriétaires) : d'où un nouveau langage. De plus le XUL a des fonctionnalités très spécifiques comme les overlays, l'usage des DTD pour les traductions et bien d'autres choses.
Bref, on a un moteur qui sait prendre n'importe quel langage XML et HTML, et sait l'afficher en le stylant en CSS.
browser.html, c'est très bien, mais ils manquent encore des choses en HTML pour faire tout ce qu'on peut faire en XUL, pour qu'il remplace ce bon cher browser.xul.
Et puis abandonner XUL, cela voudrait dire abandonner une grosse majorité des extensions… XUL va disparaitre, mais c'est pas pour demain. Il y a énormément de boulot.
[^] # Re: Et quid du portage gtk3 ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Firefox 35 heures. Évalué à 5.
Euh… Non…
Gtk ne sert pas qu'au XUL. Je dirais même, pas trop à XUL. Conçernant XUL, GTK sert juste à savoir des infos comme les couleurs systèmes, accéder aux fontes système etc. XUL, ce n'est que du HTML++ : tout est stylé en CSS. Il est vrai aussi que XUL s'appuie sur le toolkit (gtk, cocoa ou Windows) pour dessiner les boutons et quelques autres trucs d'interfaces. Et tu sais quoi ? c'est dessiné en indiquant la propriété CSS appearance. Qui sert aussi en HTML puisque cette propriété était prévu dans la spec css3-ui et reportée dans css4, mais cela n’empêche pas qu'elle soit implémentée dans Firefox et Webkit.
La présence de GTK/Cairo/Windows est surtout là pour gérer les fenêtres, ouvrir les boites de dialogues de fichier, d'impression etc du système, accéder au presse papier et de beaucoup d'autres choses.
Bref, XUL ou HTML, un navigateur a besoin d'un toolkit comme gtk et autre, en plus d'une lib purement graphique.
[^] # Re: Debian fait partie du passé
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Debian 7.8, huitième mise à jour de Wheezy. Évalué à 7.
mouahahah ptdr mdr lol
(désolé)
..
..
(ou pas, on est vendredi après tout :-) )
[^] # Re: Dommage
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal piratix.fr.nf : un tracker bittorent pour OS libres. Évalué à 0.
non, piraterie peut se dire : http://www.larousse.fr/dictionnaires/francais/piraterie/61129
[^] # Re: mocheté
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Je n'aime pas le code moderne. Évalué à 6.
<Ironie>Ouuuuh là!! Attention, tu va être TRÈS décu. en effet, beaucoup de lib et d'applis s'installe avec PIP, qui est très similaire à Composer. Tu ne vas pas pouvoir faire totalement du dev à contre courant de ce que l'écosystème propose :-p</Ironie>[^] # Re: à propos de Composer et autres
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Je n'aime pas le code moderne. Évalué à 8.
Faudrait déjà que tu définisses "industrialisé", et "usage professionnel".
[^] # Re: à propos de Composer et autres
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Je n'aime pas le code moderne. Évalué à 8.
en tant que développeur. Non. Pas du tout. Puisque j'ai même pas à connaitre l'url. Juste le nom du paquet. Une ligne dans le json (nom/version), composer install, et c'est terminé. Je veux mettre à jour ? je change la version dans le json, composer update. c'est terminé.
Alors qu'avec une archive : je dois aller la récupérer sur le site du projet, la dézipper dans mon projet, chercher à savoir comment inclure la lib, ou instancier son autoloader, et donc faire un include (voire plus) quelque part dans mon code. Ensuite, je veux mettre à jour (souvent plusieurs mois après) : faut que je retourne sur le site (dont j'ai oublié le lien, hop, détour par google), retélécharger à la mimine, dézipper les fichiers, ajouter les nouveaux fichiers dans le subversion/git, et supprimer les fichiers qui n'existent plus dans la nouvelle version (ce qui peut être fastidieux, et je parles en connaissance de cause), vérifier dans la doc que l'autoloading ou l'inclusion se fait toujours pareil…
Bah désolé, non, avec Composer, je n'ai pas toutes ces emmerdes, puisque Composer me télécharge tout ça automatiquement, qu'il m'évite à un inclure dans mon dépôt git ces libs externes, et parce que l'inclusion/autoloading, c'est Composer qui fait tout ça pour moi.
Parce que le site où tu télécharge ton zip, il ne peut pas être compromis ? tu vérifie tout les zip des libs que tu télécharges ? cela voudrait dire que tu vérifie le contenu de chaque fichier ? et pourquoi alors tu ne pourrais pas le faire dans les sources posées dans le vendor/ par Composer ?
L'argument de sécurité est nul ici.
Perso je trouve ça bête pour un utilisateur final. Mais Magento n'est pas un bon exemple pour ton argumentaire. Le lien que tu montres, c'est la doc pour les développeurs (c'est marqué sur la page). Donc oui, là, utiliser Composer a un sens. Puisque si tu es développeur, cela veut dire que tu vas personnaliser Magento, lui rajouter du code pour des traitements metiers, des plugins ou que sais-je, et donc probablement installer d'autres lib (en utilisant Composer ou pas).
Pour les utilisateurs finaux, il faut aller voir sur le site pour les utilisateurs. Et qu'y trouve-t-on ? Oh, miracle, des tar.gz prêts à l'emploi ! ;-)
Tu parlais de projets libre. Alors, à moins que pour toi une lib libre n'est pas un projet libre, je ne vois pas de différence.
Tu passes de PHP à Bootstrap, du coq à l'âne, donc des problématiques différentes. J'avoue que ton discours est très difficile à suivre.
Oui donc, au final, dans un projet, si tu utilises 25 libs, tu as alors 25 autoloaders, qui font quasiment la même chose. Bonjour les perfs. Avec Composer : on peut avoir un seul autoloader, en particulier si on utilise les namespaces (il est possible de lui indiquer des autoloaders spécifiques si nécessaire, par exemple ceux des libs ayant un autoloader spécifique).
Justement, avec Composer, on a encore moins à s'en charger, puisqu'il y a au final 0 include à faire après avoir installé une lib. Alors que, pour une lib "non composerifiée", il faut que tu saches quel fichier inclure (celui qui fait tout les includes de la lib ou qui déclare l'autoloader de la lib).
[^] # Re: à propos de Composer et autres
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Je n'aime pas le code moderne. Évalué à 5.
Moi quand je code, je veux faire les choses vite et bien, parce que ce qui m’intéresse, c'est avant tout de pouvoir répondre à un besoin. Alors si l'installation d'une lib est simplifiée, si les développeurs peuvent installer mon framework en déclarant une petite dépendance et en tapant une seule ligne de commande, ça me va.
Tu parles d'un utilisateur, ou d'un développeur ? Parce que si c'est pour fournir une application finale (un truc comme wordpress ou phpbb) destinée aux utilisateurs, oui faut être con pour proposer ce genre de chose (encore que, si Composer est installé d'office par les distros, ça peut avoir du sens). Et si je ne me trompe pas, ce genre de projet proposent en général un zip pour les utilisateurs, comportant toutes les dépendances, à déposer quelque part, prêt à être utilisé.
Pour les développeurs de l'application par contre, non, Composer facilite le développement, les mises à jours des dépendances, l'installation du projet etc… Et donc Composer convient très bien au développement.
Faut pas confondre développement et utilisation. Développeur et utilisateurs.
En ce qui concerne debian et cakephp, j'ai bien l'impression que ce que tu racontes n'a rien à voir avec Composer…
Désolé, mais tu me fais bien rire là :-) La majorité des packages installables par Composer sont des projets libres. Donc pour ces projets, ce n'est pas la solution ??? Pourquoi ils sont dans Composer alors ? Pourquoi c'est autant utilisés ?
Gniiii ??? c'est quoi cette histoire ? Pourquoi il ne faudrait pas "industrialiser" ?
Parce qu'on code une appli libre, il ne faudrait pas utiliser les outils que l'on a à notre disposition pour développer, déployer, tester et tout faire à la mimine ou rien faire ???
Bah désolé, une partie de mes projets libres, je les développe sur mon temps libre (qui se restreint de plus en plus). Tout outil qui pourrait me faire gagner du temps, qui me permettrait d'être plus productif, je les utilises.
Et c'est d'autant plus intéressant que j'en profite pour découvrir des nouveaux outils ou libs, qui me permettent ensuite au niveau professionnel de monter en compétence, d'être plus productif (et donc éventuellement d'avoir plus de temps pour dev les projets libres).
J'hallucine là. Tu trolles là en fait hein ? c'est ça ?
Je vais t'apprendre un truc : n'importe quel lib proposée par Composer, tu peux l'utiliser sans Composer. Suffit juste que tu ailles chercher toi même les dépendances, et te faire un autoloader (ce qui est une perte de temps à mon avis).
[^] # Re: mocheté
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Je n'aime pas le code moderne. Évalué à 6.
Non les traits n'est pas un paliatif. Ça n'a d'ailleurs rien à voir avec l'héritage multiple, et ça ne cherche pas à remplacer l'héritage multiple (qui pose lui même bien des problèmes dans d'autres langages).
Et il n'y a pas que PHP qui supporte les traits, il y a d'autres langages comme le tout nouveau Rust.
# Dommage
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal piratix.fr.nf : un tracker bittorent pour OS libres. Évalué à 10. Dernière modification le 15 janvier 2015 à 10:09.
Je trouve dommage que le nom du site fasse référence à la piraterie.
Les gens vont assimiler linux = warez. C'est con.
PS: ouai, ok, à priori tu milites pour le parti pirate, mais franchement sur le site, c'est pas évident à comprendre pourquoi ce mot pirate. Bref, comme pour le parti Pirate, le nom va à l'encontre des idées au final, ce qui rend le truc pas crédible.
# à propos de Composer et autres
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Je n'aime pas le code moderne. Évalué à 10.
Parce que peut-être les développeurs de ces libs ne s'y sont pas vraiment intéressé ou ne veulent pas, ou sont réfractaires à certains changement ? D'ailleurs Redbean le dit bien : le gars est "conservateur".
Cela ne veut pas dire que Composer c'est de la merde.
Et tu noteras que tu cites quand même des projets vraiment vieux (voir à peine maintenu comme PHPMailer). Lourd passif donc.
M'enfin bon, même si des libs comme celle-là ne sont pas fournie en paquet Composer, c'est juste 3 lignes de code supplémentaires à rajouter dans ton composer.json pour les intégrer dans ton projet. Pas la mort quoi.
J'ai l'impression que tu ne maintiens pas de projet public pour dire ça, ou alors tu es super compétent en design web et c'est super facile pour toi de pondre un design html/css.
J'ai plusieurs projets open source en PHP que je développe et maintien depuis des années. J'ai beau être compétent techniquement en HTML et CSS, je peux te dire une chose : ça me fais chier grave de faire les sites web de mes projets. Parce que je suis incompétent en design web et du coup, quand il faut que je refasse l'un deux, j'y passe des jours pour que ça ressemble à quelque chose. Ce temps, je préfère le passer à développer la lib. Donc je comprend très bien ceux qui choisissent bootstrap ou autre trucs "pour se faciliter la vie".
Ça c'est normal : le site de Smarty n'a pas bougé depuis 10 ans. Idem pour PHPMailer. Ils sont probablement comme moi : ils préfèrent passer du temps sur leur lib que sur le design de leur site.
Maintenant, utiliser bootstrap, ça a ses avantages : c'est responsive nativement, ça offre d’amblé un design "moderne" etc…
parce que j'ai l'impression que tu n'as pas trop en tête les avantages qu'ils offrent…
Je te rassures, même avant tout le monde boudait Pear. Quelle a été la proportion de lib et de projets qui proposait un paquet Pear ? 0,5% ? 1%? Franchement on n'y trouvait pas grand chose.
Et maintenant avec Composer ? 70%, 80%, 90% ? Le nombre de projets dispo via Composer est sans commune mesure avec Pear.
Et si Composer a un tel succès, c'est bien parce qu'il offre quelque chose de mieux non ?
Perso je n'ai jamais aimé Pear.
Déjà, c'est un truc hyper fermé : il faut que ton projet respecte certaines règles, notamment le coding style (que je trouve horrible). Ensuite, il faut qu'il soit accepté par les gens qui gère Pear. Tu ne peux pas avoir de doublons en terme de fonctionnalité avec une autre lib. Au final, Pear ne propose pas grand chose. Ou alors des usines à gaz. Interroge toi par exemple pourquoi tu as choisi PHPMailer plutôt que leur lib de mail.
Ensuite, sur le serveur (en particulier avec Debian), ton depôt PEAR est forcément partagé par tous tes projets. Au final, tu te retrouve coincé : tu ne peux pas mettre à jour au risque de casser tes vieux projets, et donc tu ne peux pas profiter des dernières versions pour des nouveaux projets. Et même si tu veux mettre à jour, c'est la galère avec debian, on ne sait jamais ce qu'il faut faire vraiment (y a toujours eu des trucs qui cassaient chez moi). Ne serait-ce que pour mettre à jour PHPUnit avec Pear. ça a toujours été la galère (à cause principalement qu'il faille faire ça en sudo, qu'il faille modifier le include_path dans la conf PHP etc).
Alors qu'avec Composer, tu as un dépôt par projet, chaque projet évolue comme il veut, utilise les paquets qu'il veut. PHPUnit et les autres paquetes s'installent en deux coup de cuillère à pot. Pas besoin de droits spéciaux sur le système pour les installer. Peu importe au final le système : ton projet reste indépendant.
M'enfin comme tu l'as dit toi même Pear c'est plus un Framework qu'un gestionnaire de dépendance. Donc au final, peu de rapport avec Composer.
Les gros avantages de Composer, c'est qu'il fait un seul truc et le fait bien : installer des paquets et gérer les dépendances. Un apt pour PHP.
L'autre gros avantage de Composer : il génère un autoloader. Adieu tous les includes dans tout les sens pour charger une lib ! Et si en plus les lib utilisent les namespaces (en respectant PSR-0 ou PSR-4), l'autoloader est beaucoup plus efficace.
À l'usage on se rend compte que ça apporte plus de souplesse, moins de tracas, et plus de perf (pas de chargement de classes non utilisées).
Ah non pas du tout ! Les PSR ne servent pas à faire en sorte que ça fonctionne quelle que soit la conf serveur. Je ne sais pas où tu as lu ça. Pour le moment, ils ont des recommandations pour le nommage des classes (PSR-0 et PSR-4), afin de faciliter le développement des autoloaders (que l'on n'a plus à développer si on utilise Composer), des recommandations sur le coding style (PSR-1 et PSR-2), et une recommandation sur l'interface d'un objet qui fait du log. Et ce qui est en discussion actuellement ce sont d'autres interfaces pour d'autres types d'objets courant (gestionnaire de cache, lib http…).
(donc non, ça ne servira pas qu'à Composer).
Bref, ce sont des choses pour améliorer l'interopérabilité entre les frameworks. Rien à voir avec la conf des serveurs.
Et puis ce ne sont que des recommandations. Pas obligé de les suivre.
Composer installe ce que les paquets ont besoin, pas plus, pas moins. Si un paquet a une dépendance envers un autre paquet et qu'il n'utilise pas, la faute est au développeur, pas à Composer. Mauvais paquet, changer paquet. (ça tombe bien, contrairement à Pear, le choix est très vaste).
Avec la nouvelle api password de PHP, cette lib est devenu inutile et obsolète (voir dangereuse, vu qu'elle n'est plus maintenue ?).
Les namespaces, c'est bon, mangez-en : ça évite les collisions de classes entre libs, ça facilite l'autoloading, ça permet une programmation moderne, ça force (un peu) à mieux organiser son code.
Je suis en train de "namespacer" mon framework, ça fait beaucoup de bien au final.
Pour finir, Composer, on peut s'en passer, mais c'est devenu la norme maintenant pour distribuer et installer des libs en PHP. L'ignorer ou le dénigrer n'aidera pas dans tes projets présent et futurs.
[^] # Re: Un bookmark légèrement plus fourni ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Weboob, la consécration. Évalué à 0.
bah pour des utilisateurs qui veulent pas voir des noms pareils à chaque fois qu'ils ouvrent leur gestionnaire d'applis.
Non, ce n'est pas comme les caricatures. Si on prend l'exemple de celles de Charlie Hebdo : si tu n'aimes pas, tu n'achètes pas le journal. Contrairement à ici où c'est imposé. On peut toujours changer de système d'exploitation, mais c'est plus compliqué que d’arrêter d'acheter un journal.
pour des gens qui donnent leur avis ? ils ont ce droit il me semble, non ?
[^] # Re: Et pourtant une autre révolution est en marche
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Tesla Motors VS the rest of the world. Évalué à 5.
oui, mais si c'est un policier qui fait signe de passer ?
[^] # Re: Chiffres
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Des nouvelles d'Electrolysis II. Évalué à 3.
Vu le nombre de bug ouvert qui bloquent la mise en prod d'electrolysis, et qui concernent des crashs ou des trucs qui ne fonctionnent plus, je dirais que ce n'est pas encore super stable :-)
Mais il est bien tout de même de tenter l'aventure et de, si possible, rapporter les bugs, afin d'aider à stabiliser cela au plus vite.
[^] # Re: Hello et TokBox business model ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Firefox 34, ce Hérault. Évalué à 2.
à priori, tu ne sembles pas comprendre comment fonctionne les plugins (aka les trucs qui se charges avec une balise object en html). Il ne t'ai pas venu à l'idée que si ils n'ont pas utilisé cela, c'est que c'était inadapté ? (les plugins sont des boites noires sur lesquels le navigateur n'a AUCUN contrôle, y compris graphique, donc intégration très limités dans les pages web).
Là tu parles des extensions XUL, pas des plugins. Un truc totalement différent.
Bah oui tient bien sûr ! Pourquoi ils n'y ont pas pensé ?? Franchement, ces développeurs, c'est tous des incompétents !
C'est vrai quoi, n'importe quel libs peut "se pluginiser" !
Non, sérieusement, tu es développeur ?
Tu as vu le nombre d'options ? Tu crois que Mozilla a les ressources nécessaires pour tester tous les cas de figure ?
Sans compter que certaines options sont des contributions externes pour des besoins spécifiques, donc non maintenue par Mozilla. D'autres sont des options qui sont là parce qu'elles étaient nécessaires lors du développement de telle ou telle fonctionnalité, puis oubliée par la suite. Enfin il peut aussi y avoir des bugs. Tu as indiqués ces bugs ? Tu es allé demander une solution ?
Peut-être parce que faire une transition franche de cette sorte, ça se fait pas en 2 secondes, que c'est très compliqué pour un projet de cet envergure. et que ça pourrait bloquer le développement d'autres choses plus prioritaires pendant un certain temps ? Et puis de toute façon, pourquoi tu demandes ça ici ? tu ne trouves pas que tu devrais plutôt demander ça directement à ceux qui le développent ?