Nicolas a écrit 576 commentaires

pourquoi être passé de Python à Php pour le projet?

Parce que lorsque tu es confronté à la vraie vie avec de vrais utilisateurs qui veulent juste que ça marche sans appeler 30 fois leur hébergeur parce qu'il manque telle extension ou parce qu'ils n'ont pas la bonne version,…, tu laisses tomber python.

p.s: Et mince j'ai marché dedans ! :-)

Google a décidé de supprimer cette possibilité de révoquer les permissions dans la dernière version, mais tu connaît toujours les permissions qu'une application demande.

J'ai android 4.3 et cette possibilité existe toujours au moins à travers une application. En revanche certaines applications n'aiment pas qu'on leur enlève des permissions et se plantent lamentablement quand cela arrive.

Et si je t'envoie mon adresse, j'ai le droit aussi aux cannelés et aux bouteilles ? :-)
Je dis ça au cas où Rodolphe n'en veuille pas. Faudrait pas gâcher !

A mon avis le temps de migration de symfony 1 à symfony 2 est bien plus court que la maintenance d'un fork.

Je connais bien symfony 1 (ayant bossé avec de la version 0.8 à 1.4 ); je suis passé il y a un peu plus d'un an à la version 2.

symfony 2 n'a que peu de rapport avec symfony 1 mais même si le vocabulaire a un peu changé, on retrouve rapidement ses petits. Si le projet est bien découplé, le passage de la version 1 à la 2 n'est pas si complexe que cela. On n'a pas besoin de tout réécrire. Toutes les classes métier restent toujours indépendantes du framework.

symfony 2 n'est pas une montagne infranchissable. Evidemment le niveau requis en programmation est un peu plus élevé que pour symfony 1 mais encore une fois rien d'insurmontable.

Même si ton projet est court (dans le temps j'entends) je pense que tu en as tiré une grande expérience. C'est ce que laisse transparaître ton journal. C'est très instructif et enrichissant. Merci.

ça risque de casser le système ?

J'ai commencé à écrire la News pour la sortie de la 2.6 finale mais sortir une news pour une RC ça me parait un peu démesuré. En fait mon journal bookmark n'a pour but que d'inciter certains à tester !

Salut,

une question : as-tu un hébergeur ? Si oui je te conseille dotclear même si je ne suis pas forcément objectif !

Je suis en train de regarder quel moteur choisir pour propulser mon futur blog (Wordpress, Dotclear ?) et cela m'intéresserait - et pas que moi je pense - de savoir un peu les nouveautés que l'on va retrouver dans la version 2.6 et les suivantes.

Ce billet qui date un peu donne des idées de que tu espérons mettre dans les prochaines versions, pas nécessairement la 2.6 mais la 2.7 ou la suivante :
http://fr.dotclear.org/blog/post/2013/03/16/Dotclear-2.5

J'ai parcouru un peu la mailing liste pour piocher des infos, mais je n'ai pas trouvé d'endroit qui donnerait une vision d'ensemble sur la roadmap.

Je suis d'accord. Peut-être faudrait-il essayer de donner plus de visibilité à cette roadmap.

La prochaine version majeur, la 2.6, sortira courant Octobre voire un peu plus tard d’après le site web, je pense que je vais tester

En effet elle promet ! Rien que pour l'interface d'administration !

ce que c’est devenu parce qu’à chaque fois j’avais un problème assez gênant avec, une page de l’administration qui était inaccessible (ça vient peut-être du serveur web que j’utilise, Nginx).

Si tu rencontres de nouveau des problèmes qui te semblent liés à Nginx, n'hésite pas à venir en faire part, on s'assiéra, on prendra un verre et on corrigera tranquillement.

Le passage de la semaine de 4,5 à 4 jours ne datent que de 2008. Il faut arrêter d'en parler comme s'il fallait demander aux grands-parents pour savoir comment c'était.
Avant 2008 les enfants étaient à l'école 4 jours et demi par semaine.

Les eval ne sont pas à tout va et sont là pour les plugins. Cela permet d'écrire du code et d'intervenir sur le core, sans vraiment le modifier.

Exemple trouvé :
php
eval($plxAdmin->plxPlugins->callHook('AdminArticlePrepend'));


La classe plxAdmin a une propriété qui contient tous les hooks sous forme de tableau. Plutôt que de faire cet eval sur du code par forcément maîtrisé, il suffit d'appeler une fonction de callback nommé. Regardez sur d'autres projets (drupal, dotclear, piwigo pour ceux que je connais) qui ont ces mécanisme de hook, ils ne font pas d'eval.

la fonction eval n'est pas le mal absolu mais ce n'est pas la peine de l'utiliser quand on n'en a pas réellement besoin.

Celui de dotclear gère apache2 / lighttpd et surtout gère l'installation des bases, mises à jour comprises.

Le package debian existe. Il est "malmené" par outils de vérification automatique debian et du coup le package n'est pas dans l'actuelle stable.
Il reste un bug "critique" (un fichier de conf d'apache écrasé par les mises à jour) qui l'empêche de rejoindre tranquillement testing.

Juste par curiosité, pourquoi voulais-tu absolument une mise à jour ? Il te manquait une fonctionnalité ?

Que pour une bonne raison on change la feuille de style par défaut, je peux le comprendre mais empêcher tout le monde de changer la feuille de style, au mieux c'est un bug …

Tu n'arriveras jamais à la version parfaite et encore moins du premier coup. Note les choses que tu vas vouloir ajouter et dès que tu as une version sans bug bloquant ou critique, fais en une version publique. Si cela intéresse quelqu'un tu auras vite des retours.
Bon courage

Euh si PHP a d'énormes problèmes de sécurité,

Je dois avouer que quand j'ai vu 2007 pour l'année je n'ai même pas fait l'effort de lire plus loin…

… et il n'aide pas d'ailleurs à éviter dans mettre dans son propre code tellement il est mal fichu et sans aucune convention

Admettons et donc le problème de sécurité est bien le programmeur lui-même et pas le langage qu'il utilise. On ne pas désigner directement l'outil comme mauvais du fait qu'on l'ai donné à un ouvrier qui ne le maîtrisait pas.

Après je veux bien reconnaître que le langage n'aide pas les débutants à avoir les bonnes pratiques.

Et comme d'habitude c'est du PHP (avec les conséquences de sécurité qui vont avec).

Les problèmes de sécurité ne sont pas liés au langage mais à l'interface chaise clavier !

Pareil, que du MySQL, impossible d'utiliser PostgreSQL qui affiche de meilleures performances.

En même temps, il a le bon goût d'utiliser pdo (abstraction de base de données) et du coup le portage vers d'autres sgbd(r) est est grandement facilité.

Ça reste un CMS parmi tant d'autres, rien d'innovant.

On attend plus que ta contribution.

Je partage globalement ton avis même si j'avoue que ce ne serait pas forcément facile de se remettre en cause et risquer de perdre sa place. Mais cela pousserait sûrement les gens à continuer d'évoluer, de se battre, de se former pour garder une place ou pour en trouver une autre, voire une meilleure.

Ma question : jusqu'à quel âge ? Je vois (peut-être à tort) le CDI comme une sorte de récompense de stabilité après être passé par les cases chômages, CDD, SSII, … En approchant de l'âge de la retraire (tant qu'elle existe), je ne pense pas qu'on est la même hargne pour chercher un nouveau boulot ou pour garder celui qu'on occupe.
En clair, que fait-on des vieux ?

Il y a quelque chose que je ne comprends pas : pourquoi ne pas formater les cardes SD en ext3 ? On peut lire et écrire depuis n'importe quel OS. Quel est le soucis ?

Et quand on est locataire on fait comment ? On repart avec son carton d'ampoules ?

Et j'ajouterais que le commentaire suivant :

Pas optimisé pour l'utilisation avec un reverse proxy : aucun header lié au cache positionné (Expires…). Au final, tout le monde utilise "WP-Supercache" qui ne résoud que partiellement le problème

Je ne suis pas sûr de savoir de quoi tu parles, mais ce dont je suis sûr, c'est que Django doit certainement le permettre de base.

J'ai encore plus de doute sur ses compétences.

Effectivement, la version 8 va utiliser de nombreux composants issus de Symfony. J'y vois plein d'intérêt pour tenter de mutualiser les compétences. Je pense que les deux projets (Symfony et drupal) ont a y gagner.

Pour avoir jouer avec la version de développement de drupal 8, ce ne sera quand même pas une révolution, en tout cas côté visiteur ! Sous le capot c'est en revanche bien autre chose, et on y retrouvera plein de bonnes pratiques : composer, composant http,…

Comme pour les précédentes versions, le risque est de ne pas avoir suffisamment de modules portés sur la dernière version.

Dans install/install.txt, j'ai trouvé :
Si vous êtes sous PHP 5.x, n'oubliez de passer la variable "registerlong_arrays" à "On" dans le php.ini_

C'est bien évidemment le contraire qu'il faut faire !