"Forcer" est un raccourci que j'aurai dû utiliser avec plus de parcimonie.
Je m'étonne simplement du fait que certaines libs ou certains outils (PHPUnit me vient en premier à l'esprit) mettent en avant les deux méthodes d'installation (avec ou sans composer), alors que d'autres non.
Oui, bien sûr, on peut utiliser une lib sans composer. Mais on nous "force" la main quand même en ne precisant pas dans la doc de ces libs comment les installer sans composer. Un simple lien suffirait.
Allez, Linux ne compile qu'avec GCC, ça restreint ma liberté de choisir mon compilo, Linux est contre le philosophie du libre. Ou pas. tu peux toujours inventer un truc à ce niveau.
Là tu extrapole.
Déjà parce que Linux dépend de certaines extensions de GCC. Une lib qui veut s'installer via composer ne dépend pas de librairies de ce dernier (qui n'en a pas) pour fonctionner, elle fonctionne en toute autonomie.
Ensuite, comparer quelque chose d'aussi critique que le noyau Linux et une librairie PHP qui fait du routage pour une app web, c'est osé…
Oui. Du coup tu dis toi-même que tes idées sur le libre sont fausses. J'avoue ne pas comprendre à quoi tu veux en venir.
Je ne dis pas que mes idées sont fausses, je dis qu'il n'y a pas de raison d'obliger un dev à passer par composer pour installer sa lib. Comme je l'ai dis plus tôt, PHPUnit propose les deux méthodes d'installation, c'est donc qu'il est possible de laisser le choix aux développeurs de leur méthode d'installation. Et bien que nous ayons la possibilité de modifier ces outils à notre convenance, tout l'intérêt d'utiliser une lib est de se simplifier la vie, et réduire le temps passé à l'adaptation de l'existant. C'est encore plus embêtant quand on suit des recommandations d'interopérabilité.
Ben disons que quand l'auteur d'un post dit que ce post est n'importe quoi sans arrêter de penser que son post est correct, on a du mal à suivre. C'est quoi le but de cette mascarade?
Je ne dis ni que mon post est n'importe quoi, ni qu'il est correct. C'est mon journal, j'y écris mon ressenti. Peut être que je m'y exprime mal, mais d'autres dans les commentaires ont compris ma démarche.
Si tu n'as pas compris le but de mon journal, je t'invite à le relire. Je me suis peut être mal exprimé dans mes commentaires, mais il me semble avoir été plus que clair en disant que je n'aime pas le code moderne :)
Toujours dans un soucis de clarification, ce que tu appelle "masquarade", j'appelle ça "un coup de gueule passé contre les librairies qui forcent les devs à utiliser des outils dont ils ne veulent pas sans pouvoir justifier d'une liaison si forte entre la librairie et l'outil que le premier ne peut être installé sans le second". Sur ce point aussi, il me semble avoir été clair tout au long des commentaires.
Dans le premier cas tu juges l'application sur le fait que le maximum soit mis sur l'apparence du site web, dans le deuxième cas tu juges l'application sur le fait que le maximum ne soit pas mis sur l'apparence du site web (piège oisif).
Non, ce que je voulais dire c'est qu'on peut faire un site vite fait bien fait sans bootstrap :)
Un normalizer pour la compatiblité, deux trois classes pour les liens ou les menus et voilà, pas besoin de pondre du less pour une page de présentation de la lib.
Si c'est la syntaxe des traits et des namespaces qui te pose problème tu devrais vite changer de langage ! Parce que les incohérences de syntaxe dans PHP sont légions
Oui, ça, je suis parfaitement d'accord. Les incohérences sont nombreuses et la dev team de PHP n'est pas encline à les corriger.
Je lorgne de plus en plus du côté de Python. Si je ne m'y suis pas encore mis, c'est parce que je veux concevoir des applications Libres que le débutant peut installer facilement. Je me disais qu'une appli PHP était plus simple à installer qu'une appli Python (en terme de paramétrage de serveur web notamment).
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 :)
« Logiciel libre » [free software] désigne des logiciels qui respectent la liberté des utilisateurs
Je sais, c'est de l'interprétation, mais pour moi ça implique que si une lib m'impose d'utiliser composer, ça restreint ma liberté.
PHPUnit permet les deux types d'installation (comme d'autres). Ça, c'est la bonne façon de faire, respectueuse de la liberté des devs.
Tu me diras, je suis libre de ne pas utiliser les libs qui me forcent à utiliser composer, je suis libre de les modifier pour les adapter à mon besoin, et ça, elles ne m'empêchent pas de le faire. Du coup on tourne en rond et la discussion devient stérile :)
"encore une application moderne qui mise sur l'apparence" et "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" c'est contradictoire.
Vraiment, j'essaye de comprendre, mais je ne vois toujours pas en quoi c'est contradictoire.
Alors fais toi plaisir : les traits, les namespaces, Composer, ne sont pas bancals ou alors je veux bien que tu m'expliques en quoi.
Les traits sont un paliatif au fait que PHP ne supporte pas l'héritage multiple. Je trouve leur syntaxe confuse:
class MaClass {
use MyTrait1, MyTrait2;
[...]
Premièrement, jusqu'à présent, le mot-clé use n'était utilisé que pour importer une variable dans une closure. Là on a le sentiment d'importer une classe dans une autre, ce qui n'est pas exact. Je pense qu'il aurait été plus harmonieux de faire quelque chose du genre:
class MaClass extends MyTrait1, MyTrait2 {
[...]
Pour les namespaces, là aussi c'est la syntaxe qui me pose problème. L'antislash n'est pas un bon séparateur selon moi, le slash aurait été plus approprié, plus logique.
Enfin pour composer, j'ai expliqué en quoi il est bancal dans un autre commentaire de ce topic.
Je suis développeur, pas graphiste. Les sites beaux je sais pas faire ça tout seul.
Et tu ne lis pas les posts en entier :)
Enfin bref tu te contredis
Pardon, je ne vois pas où je me contredis…
et mélanges un peu tout
Oui, je parle du code moderne, donc ça englobe un certain nombre de choses…
juste pour nous dire que tu n'as pas envie d'évoluer et d'apprendre de nouvelles technos
J'utilise bootstrap dans mes projets persos non diffusés, j'utilise CakePHP dans les devs pro, j'utilise foundation dans certains projets, ink (du même auteur) pour les mails HTML. Qui a dit que je ne voulais pas évoluer ou apprendre de nouvelles technos ?
Je ne suis simplement pas prêt à accepter la modernité juste pour dire que j'utilise quelque chose de moderne.
Par ailleurs, quand ces outils modernes fonctionnent, je les utilise avec plaisir. Par contre, je ne suis pas d'accord avec l'obligation d'utiliser un outil moderne pour utiliser des librairies bancales.
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.
Moi, ce que je vois avec composer, c'est que quand tu code une appli libre, tu cherche à simplifier au maximum l'installation.
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. D'autant que composer semble ne pas fonctionner partout de la même façon: sous Mac OSX, l'installation de CakePHP se fait exactement comme dans la doc officielle. Sous Debian, l'arborescence de vendor n'est pas la même et il devient impossible de charger le bootstrap de CakePHP sans modifier une variable pour mette le chemin en dur parce que sous Debian, il chope le repo git au lieu du repo PEAR (ou l'inverse, je ne sais plus).
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.
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.
Je suis loin d'être compétent en web design. Mais bootstrap, comme tout framework qu'il soit front ou back end, est fait pour industrialiser. Quand on code une appli libre, on n'industrialise pas. On industrialise quand on se fait plein de petits projets pour soi-même. Moi aussi j'utilise bootstrap quotidiennement pour mes projets perso (genre gestion DNS, gestion d'Apache, PKI, etc.), mais pour des applications Libres, je n'utilise que normalizer (sur lequel repose bootstrap). Pour les projets pros, pareil.
Maintenant, utiliser bootstrap, ça a ses avantages : c'est responsive nativement, ça offre d’amblé un design "moderne" etc…
Je me suis peut être mal exprimé: je ne dis pas que bootstrap c'est de la merde, je dis qu'il faut arrêter d'en mettre partout. Je reste d'accord avec ce que tu dis.
Je te rassures, même avant tout le monde boudait Pear
Pas faux, le problème d'être élitiste :)
ton depôt PEAR est forcément partagé par tous tes projets
C'est un détail, mais non. Tu peux parfaitement utiliser PEAR pour un unique projet (c'est ce que fait Roundcube par exemple, qui n'a jamais nécessité d'installer PEAR alors qu'il en utilise des libs)
Pareil Horde permet d'être installé avec sa propre instance de PEAR (leur site est + ou - down là sinon j'aurai mis un lien).
À 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)
Oui, je suis d'accord, mais ça serait mieux sans les pseudo-dépendances qui n'existent pas dans les archives !
Ou alors, les paquets composer sont structurés différemment des archives, ce qui forcerait les dev à maintenir deux paquets différents ?
Ah non pas du tout ! Les PSR ne servent pas à faire en sorte que ça fonctionne quelle que soit la conf serveur.
Oui pardon je me suis enflammé ^
Ceci dit ils parlent d'interopérabilité, j'ai pensé que ça avait un sens un poil plus large…
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.
C'est bien là que le bât blesse: quelque chose qui n'a rien à voir avec PHP devient la norme pour développer avec PHP.
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.
Tout ce que tu viens de linker repose sur Symfony (ou codé par les gars de Symfony, donc avec la même philosophie) qui… on va dire n'est pas fait pour les conservateurs ^
100% d'accord avec tes remarques sur Symfony, et c'est bien de lui que je parlais quand je disais "Du code logique dans les commentaires ?" (ça a peut être changé depuis ceci dit)
Jamais dis que PHP ne me convenait plus: ce sont les "trucs" modernes qui ne me conviennent pas, et surtout, la quasi obligation de passer par des outils comme composer pour choper des libs.
Je ne dis pas non plus que tous les trucs modernes me dérangent: Redbean est une lib moderne développée par un conservateur. Ça pour moi c'est l'idéal du développement en PHP.
Ce que je critique c'est que le web est inondé de sites dont le front-end repose sur bootstrap peu ou prou modifié, et qu'il y en a marre de voir des clones de bootstrap partout.
Je ne dis pas qu'il faut faire un site ultra beau et abouti pour présenter une librairie (justement, je dis bien que le site de Smarty est vétuste et celui de Redbean est simple et sobre). Je dis que quand on est un dev web et qu'on fait du Libre, on pourrait se creuser un peu la soupière pour faire quelque chose qui ne repose pas sur Bootstrap.
Utiliser Foundation par exemple, ça changerait un peu…
Ah non je l'affirme: cf documentaire "Une contre-histoire de l'Internet".
Quand on est une association et qu'on demande de l'argent, on évite les signes extérieurs de richesse, en tout cas pas à la TV, enfin ça me semble un minimum.
On pourra me rétorquer que ces cigares ont probablement été payés avec les deniers personnels des fumeurs, soit, mais on parle de l'image de l'association alors…
D'accord alors plus clairement: je n'ai pas l'intérêt de m'y mettre sur un plan privé, et je n'ai pas eu l'occasion de m'y mettre sur le plan professionnel :)
Merci pour l'info. Je m'étais penché sur OpenWrt, mais je me sentais plus à l'aise avec Debian que je connais depuis longtemps et que j'affectionne particulièrement ^
Je te conseille quand même de tester ZeroShell qui est extrêment léger (il tourne sur une clé USB, pas d'installation sur disque) et très facile à configurer, même si tu passe à Pfsense ensuite.
Pour ce qui est des deux WAN, à la base il y en avait une payée par mon boulot et l'autre était pour le "perso". La boîte a fermée mais je trouvais ça confortable d'avoir deux connexions :)
A part Pfsense, je n'ai trouvé aucun OS libre qui permette de faire du fail-over + du load-balancing + les autres fonctionnalités que je voulais implémenter. ZeroShell est pas mal mais ne gère pas IPv6 et ne me permet pas de facilement faire du blocage DNS, Untangle a des fonctionnalités payantes, ClearOS m'a semblé relativement lent quand je l'ai essayé en local. IpCop, IpFire, Monowall ne supportent pas deux WAN, etc.
En le faisant moi-même, c'est du sur-mesure: là je gère moi-même la liste des domaine bloqués directement sur la passerelle avec un proxy Apache pour les sites situés sur les réseaux internes où qu'ils soient (par exemple j'utilise PhotoStation sur le NAS qui est sur le LAN, mais n'est pas directement exposé puisqu'Apache sur Cerbere fait office de proxy avec mod_security), c'est Cerbere qui gère le freeRADIUS (plus logique que de laisser ça au NAS par exemple, ce que je faisais avant de monter ce réseau)
Quant aux firewall hardware, soit ils sont trop chers, soit ils manquent de fonctionnalités (j'ai l'habitude de recommander TP-Link par exemple, qui sont excellents outre le manque de souplesse au niveau du DHCP, impossible de specifier un next-server avec filename pour faire du netboot par exemple). J'avais vu aussi les produits de Microtik (ils ont des routeurs sexy…) mais RouterOS a l'air d'être une vacherie à gérer…
Je passe très vite sur le multimédia en effet parce que j'ai surtout voulu parler du dual-WAN :)
Mais pour faire simple: je n'ai rien de spécial à faire, merci Synology ! Il suffit d'installer {Photo,Video,Music}Station sur le NAS, et les applications Android correspondantes pour que le NAS transcode à la volée les flux et que le terminal Android les lise sans encombre (y compris les flux HD même si le terminal ne supporte pas une telle résolution, le tout sans saccade). Précision: ça marche très bien aussi avec mon téléviseur et ma platine Blu-ray, l'essentiel pour ce type de terminal étant qu'il soit compatible DLNA. Les platines Dune passent par les partages CIFS par contre.
Pour les partages, toujours depuis le NAS, c'est tout en CIFS (donc partages Windows) et NFS pour le TFTP. Les autorisations sont simplement données par les acls que le NAS permet de gérer très finement. Et pour l'accès depuis un périphérique DLNA, tu peux spécifier les adresses IP autorisées à se connecter. Depuis un périphérique Android, c'est les comptes utilisateurs du NAS qui sont utilisés.
Autre question bête
J'ai connu un coach qui disait "Il n'y a pas de question bête, seules les réponses peuvent l'être" :)
[^] # Re: Plutôt d'accord
Posté par Richard Dern . En réponse au journal Je n'aime pas le code moderne. Évalué à 1.
Merci pour le lien !
[^] # Re: Python c'est mieux maintenant
Posté par Richard Dern . En réponse au journal Je n'aime pas le code moderne. Évalué à -2.
L'intérêt est surtout de faciliter le développement sans ciblage d'une BDD spécifique en l'occurrence.
[^] # Re: à propos de Composer et autres
Posté par Richard Dern . En réponse au journal Je n'aime pas le code moderne. Évalué à -6.
"Forcer" est un raccourci que j'aurai dû utiliser avec plus de parcimonie.
Je m'étonne simplement du fait que certaines libs ou certains outils (PHPUnit me vient en premier à l'esprit) mettent en avant les deux méthodes d'installation (avec ou sans composer), alors que d'autres non.
Oui, bien sûr, on peut utiliser une lib sans composer. Mais on nous "force" la main quand même en ne precisant pas dans la doc de ces libs comment les installer sans composer. Un simple lien suffirait.
[^] # Re: à propos de Composer et autres
Posté par Richard Dern . En réponse au journal Je n'aime pas le code moderne. Évalué à -2.
Là tu extrapole.
Déjà parce que Linux dépend de certaines extensions de GCC. Une lib qui veut s'installer via composer ne dépend pas de librairies de ce dernier (qui n'en a pas) pour fonctionner, elle fonctionne en toute autonomie.
Ensuite, comparer quelque chose d'aussi critique que le noyau Linux et une librairie PHP qui fait du routage pour une app web, c'est osé…
Je ne dis pas que mes idées sont fausses, je dis qu'il n'y a pas de raison d'obliger un dev à passer par composer pour installer sa lib. Comme je l'ai dis plus tôt, PHPUnit propose les deux méthodes d'installation, c'est donc qu'il est possible de laisser le choix aux développeurs de leur méthode d'installation. Et bien que nous ayons la possibilité de modifier ces outils à notre convenance, tout l'intérêt d'utiliser une lib est de se simplifier la vie, et réduire le temps passé à l'adaptation de l'existant. C'est encore plus embêtant quand on suit des recommandations d'interopérabilité.
Je ne dis ni que mon post est n'importe quoi, ni qu'il est correct. C'est mon journal, j'y écris mon ressenti. Peut être que je m'y exprime mal, mais d'autres dans les commentaires ont compris ma démarche.
Si tu n'as pas compris le but de mon journal, je t'invite à le relire. Je me suis peut être mal exprimé dans mes commentaires, mais il me semble avoir été plus que clair en disant que je n'aime pas le code moderne :)
Toujours dans un soucis de clarification, ce que tu appelle "masquarade", j'appelle ça "un coup de gueule passé contre les librairies qui forcent les devs à utiliser des outils dont ils ne veulent pas sans pouvoir justifier d'une liaison si forte entre la librairie et l'outil que le premier ne peut être installé sans le second". Sur ce point aussi, il me semble avoir été clair tout au long des commentaires.
[^] # Re: mocheté
Posté par Richard Dern . En réponse au journal Je n'aime pas le code moderne. Évalué à 2.
Source: http://php.net/manual/en/language.oop5.traits.php
L'objectif reste bien d'utiliser les méthodes d'une classe dans une autre, donc quelque part faire de l'héritage. Non ?
[^] # Re: mocheté
Posté par Richard Dern . En réponse au journal Je n'aime pas le code moderne. Évalué à 1.
Non, ce que je voulais dire c'est qu'on peut faire un site vite fait bien fait sans bootstrap :)
Un normalizer pour la compatiblité, deux trois classes pour les liens ou les menus et voilà, pas besoin de pondre du less pour une page de présentation de la lib.
Oui, ça, je suis parfaitement d'accord. Les incohérences sont nombreuses et la dev team de PHP n'est pas encline à les corriger.
Je lorgne de plus en plus du côté de Python. Si je ne m'y suis pas encore mis, c'est parce que je veux concevoir des applications Libres que le débutant peut installer facilement. Je me disais qu'une appli PHP était plus simple à installer qu'une appli Python (en terme de paramétrage de serveur web notamment).
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 :)
[^] # Re: à propos de Composer et autres
Posté par Richard Dern . En réponse au journal Je n'aime pas le code moderne. Évalué à -3.
Je sais, c'est de l'interprétation, mais pour moi ça implique que si une lib m'impose d'utiliser composer, ça restreint ma liberté.
PHPUnit permet les deux types d'installation (comme d'autres). Ça, c'est la bonne façon de faire, respectueuse de la liberté des devs.
Tu me diras, je suis libre de ne pas utiliser les libs qui me forcent à utiliser composer, je suis libre de les modifier pour les adapter à mon besoin, et ça, elles ne m'empêchent pas de le faire. Du coup on tourne en rond et la discussion devient stérile :)
[^] # Re: mocheté
Posté par Richard Dern . En réponse au journal Je n'aime pas le code moderne. Évalué à 1.
Vraiment, j'essaye de comprendre, mais je ne vois toujours pas en quoi c'est contradictoire.
Les traits sont un paliatif au fait que PHP ne supporte pas l'héritage multiple. Je trouve leur syntaxe confuse:
Premièrement, jusqu'à présent, le mot-clé use n'était utilisé que pour importer une variable dans une closure. Là on a le sentiment d'importer une classe dans une autre, ce qui n'est pas exact. Je pense qu'il aurait été plus harmonieux de faire quelque chose du genre:
Pour les namespaces, là aussi c'est la syntaxe qui me pose problème. L'antislash n'est pas un bon séparateur selon moi, le slash aurait été plus approprié, plus logique.
Enfin pour composer, j'ai expliqué en quoi il est bancal dans un autre commentaire de ce topic.
[^] # Re: mocheté
Posté par Richard Dern . En réponse au journal Je n'aime pas le code moderne. Évalué à 1.
Et tu ne lis pas les posts en entier :)
Pardon, je ne vois pas où je me contredis…
Oui, je parle du code moderne, donc ça englobe un certain nombre de choses…
J'utilise bootstrap dans mes projets persos non diffusés, j'utilise CakePHP dans les devs pro, j'utilise foundation dans certains projets, ink (du même auteur) pour les mails HTML. Qui a dit que je ne voulais pas évoluer ou apprendre de nouvelles technos ?
Je ne suis simplement pas prêt à accepter la modernité juste pour dire que j'utilise quelque chose de moderne.
Par ailleurs, quand ces outils modernes fonctionnent, je les utilise avec plaisir. Par contre, je ne suis pas d'accord avec l'obligation d'utiliser un outil moderne pour utiliser des librairies bancales.
[^] # Re: à propos de Composer et autres
Posté par Richard Dern . En réponse au journal Je n'aime pas le code moderne. Évalué à 2.
Moi, ce que je vois avec composer, c'est que quand tu code une appli libre, tu cherche à simplifier au maximum l'installation.
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. D'autant que composer semble ne pas fonctionner partout de la même façon: sous Mac OSX, l'installation de CakePHP se fait exactement comme dans la doc officielle. Sous Debian, l'arborescence de vendor n'est pas la même et il devient impossible de charger le bootstrap de CakePHP sans modifier une variable pour mette le chemin en dur parce que sous Debian, il chope le repo git au lieu du repo PEAR (ou l'inverse, je ne sais plus).
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.
Je suis loin d'être compétent en web design. Mais bootstrap, comme tout framework qu'il soit front ou back end, est fait pour industrialiser. Quand on code une appli libre, on n'industrialise pas. On industrialise quand on se fait plein de petits projets pour soi-même. Moi aussi j'utilise bootstrap quotidiennement pour mes projets perso (genre gestion DNS, gestion d'Apache, PKI, etc.), mais pour des applications Libres, je n'utilise que normalizer (sur lequel repose bootstrap). Pour les projets pros, pareil.
Je me suis peut être mal exprimé: je ne dis pas que bootstrap c'est de la merde, je dis qu'il faut arrêter d'en mettre partout. Je reste d'accord avec ce que tu dis.
Pas faux, le problème d'être élitiste :)
C'est un détail, mais non. Tu peux parfaitement utiliser PEAR pour un unique projet (c'est ce que fait Roundcube par exemple, qui n'a jamais nécessité d'installer PEAR alors qu'il en utilise des libs)
Pareil Horde permet d'être installé avec sa propre instance de PEAR (leur site est + ou - down là sinon j'aurai mis un lien).
Oui, je suis d'accord, mais ça serait mieux sans les pseudo-dépendances qui n'existent pas dans les archives !
Ou alors, les paquets composer sont structurés différemment des archives, ce qui forcerait les dev à maintenir deux paquets différents ?
Oui pardon je me suis enflammé ^
Ceci dit ils parlent d'interopérabilité, j'ai pensé que ça avait un sens un poil plus large…
C'est bien là que le bât blesse: quelque chose qui n'a rien à voir avec PHP devient la norme pour développer avec PHP.
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.
[^] # Re: Laravel + Twig semble pas mal
Posté par Richard Dern . En réponse au journal Je n'aime pas le code moderne. Évalué à 0.
Tout ce que tu viens de linker repose sur Symfony (ou codé par les gars de Symfony, donc avec la même philosophie) qui… on va dire n'est pas fait pour les conservateurs ^
[^] # Re: Plutôt d'accord
Posté par Richard Dern . En réponse au journal Je n'aime pas le code moderne. Évalué à 4.
100% d'accord avec tes remarques sur Symfony, et c'est bien de lui que je parlais quand je disais "Du code logique dans les commentaires ?" (ça a peut être changé depuis ceci dit)
[^] # Re: Python c'est mieux maintenant
Posté par Richard Dern . En réponse au journal Je n'aime pas le code moderne. Évalué à 0.
Jamais dis que PHP ne me convenait plus: ce sont les "trucs" modernes qui ne me conviennent pas, et surtout, la quasi obligation de passer par des outils comme composer pour choper des libs.
Je ne dis pas non plus que tous les trucs modernes me dérangent: Redbean est une lib moderne développée par un conservateur. Ça pour moi c'est l'idéal du développement en PHP.
[^] # Re: mocheté
Posté par Richard Dern . En réponse au journal Je n'aime pas le code moderne. Évalué à -4.
Ce que je critique c'est que le web est inondé de sites dont le front-end repose sur bootstrap peu ou prou modifié, et qu'il y en a marre de voir des clones de bootstrap partout.
Je ne dis pas qu'il faut faire un site ultra beau et abouti pour présenter une librairie (justement, je dis bien que le site de Smarty est vétuste et celui de Redbean est simple et sobre). Je dis que quand on est un dev web et qu'on fait du Libre, on pourrait se creuser un peu la soupière pour faire quelque chose qui ne repose pas sur Bootstrap.
Utiliser Foundation par exemple, ça changerait un peu…
[^] # Re: Pourquoi ?
Posté par Richard Dern . En réponse au journal Quadrature is dying. Évalué à 1.
/me se sent comme Manny le Mammouth ;)
[^] # Re: Pourquoi ?
Posté par Richard Dern . En réponse au journal Quadrature is dying. Évalué à 9.
Ah non je l'affirme: cf documentaire "Une contre-histoire de l'Internet".
Quand on est une association et qu'on demande de l'argent, on évite les signes extérieurs de richesse, en tout cas pas à la TV, enfin ça me semble un minimum.
On pourra me rétorquer que ces cigares ont probablement été payés avec les deniers personnels des fumeurs, soit, mais on parle de l'image de l'association alors…
[^] # Re: Pourquoi ?
Posté par Richard Dern . En réponse au journal Quadrature is dying. Évalué à 5.
A payer les barreaux de chaise fumés pendant les interviews ?
J'ai l'impression d'être le seul que ça a choqué.
[^] # Re: un petit réseau standard quoi !
Posté par Richard Dern . En réponse au journal Mon réseau (aussi). Évalué à 1.
En effet, à partir du moment où il n'y a pas d'application cliente tu dois avoir du DLNA.
[^] # Re: Bah merde alors!
Posté par Richard Dern . En réponse au journal Mon réseau (aussi). Évalué à 1.
D'accord alors plus clairement: je n'ai pas l'intérêt de m'y mettre sur un plan privé, et je n'ai pas eu l'occasion de m'y mettre sur le plan professionnel :)
[^] # Re: Bah merde alors!
Posté par Richard Dern . En réponse au journal Mon réseau (aussi). Évalué à 1.
Merci de l'info, effectivement j'avais raté ça.
[^] # Re: Bah merde alors!
Posté par Richard Dern . En réponse au journal Mon réseau (aussi). Évalué à 1.
Je sens comme un jugement poindre de ta question :)
Je ne vois pas d'intérêt à faire de la virtualisation sur mon réseau.
Néanmoins je connais son utilité dans d'autres circonstances.
[^] # Re: À propos du Cerbère.
Posté par Richard Dern . En réponse au journal Mon réseau (aussi). Évalué à 1.
Merci pour l'info. Je m'étais penché sur OpenWrt, mais je me sentais plus à l'aise avec Debian que je connais depuis longtemps et que j'affectionne particulièrement ^
[^] # Re: À propos du Cerbère.
Posté par Richard Dern . En réponse au journal Mon réseau (aussi). Évalué à 1.
Je te conseille quand même de tester ZeroShell qui est extrêment léger (il tourne sur une clé USB, pas d'installation sur disque) et très facile à configurer, même si tu passe à Pfsense ensuite.
Pour ce qui est des deux WAN, à la base il y en avait une payée par mon boulot et l'autre était pour le "perso". La boîte a fermée mais je trouvais ça confortable d'avoir deux connexions :)
[^] # Re: À propos du Cerbère.
Posté par Richard Dern . En réponse au journal Mon réseau (aussi). Évalué à 2.
[^] # Re: un petit réseau standard quoi !
Posté par Richard Dern . En réponse au journal Mon réseau (aussi). Évalué à 3.
Je passe très vite sur le multimédia en effet parce que j'ai surtout voulu parler du dual-WAN :)
Mais pour faire simple: je n'ai rien de spécial à faire, merci Synology ! Il suffit d'installer {Photo,Video,Music}Station sur le NAS, et les applications Android correspondantes pour que le NAS transcode à la volée les flux et que le terminal Android les lise sans encombre (y compris les flux HD même si le terminal ne supporte pas une telle résolution, le tout sans saccade). Précision: ça marche très bien aussi avec mon téléviseur et ma platine Blu-ray, l'essentiel pour ce type de terminal étant qu'il soit compatible DLNA. Les platines Dune passent par les partages CIFS par contre.
Le NAS et les téléchargements: https://www.synology.com/fr-fr/products/DS214play.
Pour les partages, toujours depuis le NAS, c'est tout en CIFS (donc partages Windows) et NFS pour le TFTP. Les autorisations sont simplement données par les acls que le NAS permet de gérer très finement. Et pour l'accès depuis un périphérique DLNA, tu peux spécifier les adresses IP autorisées à se connecter. Depuis un périphérique Android, c'est les comptes utilisateurs du NAS qui sont utilisés.
J'ai connu un coach qui disait "Il n'y a pas de question bête, seules les réponses peuvent l'être" :)
Absolument.