Design & Développement web - Le topic des canards qui mangent des cookies

[Tomaka17]

Moi je génère mes pages XHTML avec du XSLT et j'assume.

Nan honnêtement, quand je vois des trucs comme twig, il ne fait absolument rien de plus que du simple XSLT 1.0.

[tenshu]

Moi je génère mes pages XHTML avec du XSLT et j'assume.

Nan honnêtement, quand je vois des trucs comme twig, il ne fait absolument rien de plus que du simple XSLT 1.0.

Mais de façon plus accessible.

Je défendrais pas trop le truc, je trouve que php en syntaxe brève est déjà suffisant comme moteur de template.

[elpaulo]

Ce code HTML est par exemple tout à fait correct :

<table>
<tr>
  <td><p>Colonne 1
  <td><p>Colonne 2
  <td><p>Colonne 3
</tr>
</table>

Tout a fait correct, peut être, mais tout a fait dégueulasse et illisible aussi. Tu n'as jamais la notion de la fin d'un TD ici, et si tu as beaucoup de code dans cette cellule c'est la mort si la seule chose qui t'indique que tu changes de cellule c'est de trouver un nouveau TD ouvrant. La manière dont tu l'as écrit fait que ca passe encore mais imagine le gars qui l'écrit comme ca :

<table>
<tr><td>
<p>
Colonne 1
  <td><p>Colonne 2
  <td>
<p>Colonne 3
</tr></table>

C'est beau hein ? Tu me diras, c'est de la responsabilité du dev d'écrire du HTML proprement, mais pour la maintenance, n'importe quel soft qui lit du xml ou du html bien structuré avec les balises fermées sera capable de comprendre ca :

<table>
<tr>
  <td>
    <p>Colonne 1</p>
  </td>
  <td>
    <p>Colonne 2</p>
  </td>
  <td>
    <p>Colonne 3</p>
  </td>
</tr>
</table>

Alors qu'avec ton truc de goret, tu peux te brosser

[Anon26492]

Bah, les tables tu t'en tapes, elles sont générées par Dreamweaver

[tenshu]

Bah, les tables tu t'en tapes, elles sont générées par Dreamweaver

A la question, "cette blague n'a t'elle pas trop vécue ?".
Ma réponse est toujours non.

[darkgrievous]

Bah, les tables tu t'en tapes, elles sont générées par Dreamweaver

BAn !

Et dire que j'ai du corriger ce genre de truc ce matin

[Skiant]

Bah, les tables tu t'en tapes, elles sont générées par Dreamweaver

Oh le mignon petit trollounet. T'as vraiment du mal à te retenir, hein ?

Sinon, parce que ta bêtises pourrait induire des débutants en erreur, les tables, c'est pas totalement hors de propos. C'est même plus qu'indiqué quand vous devez afficher des données tabulaires.
Parce que tout aussi con que les layouts en tables en 2012, y'a aussi les mecs à qui on a bourré le crâne de "les tables c'est mal" et qui font des listes avec des "float" dans tous les sens pour afficher des données comparatives.

[Tomaka17]

Je vois pas où y aurait un troll dans la mesure où absolument tout le monde est d'accord sur le sujet. Un troll c'est quand tu balances un truc non-constructif qui déclenche une polémique, je vois pas où pourrait être la polémique ici.
Bref.

En tout cas, RDJ : Dreamweaver ça existe encore

[Anon26492]

Complètement.
Non seulement Skiant voit un troll dans une blaguounette consensuelle, mais en plus il trolle lui-même en inventant un problème à mon message et en reliant les mecs qui font des tables à base de display:inline-block.

C'est un peu l'hôpital qui se fout de la charité


Protip : quand je trolle, ça déclenche une flamewar sur cinq pages dont la shitstorm éclabousse les topics adjacents et qui termine par une descente des modos


Topic sérieux ne veut pas non plus dire topic triste. On est sur CPC.

[flo900]

Mais derrière Heroku y'avait pas aussi le concepteur du langage Ruby ?

Ça + écosystème PAAS beaucoup moins développé qu'aujourd'hui, effectivement le choix était vite fait.

J'avais lu un article intéressant où l'un des créateurs d'un site de petites annonces avaient été leader et énormément en avance par rapport aux autres parce que son site était développé en Lisp. Impossible de retrouver cela par contre.

D'ailleurs ça me fait penser à cet article où grosso merdo, le mec explique que sa boite était ultra-réactive de part le langage utilisé : Lisp

Sinon pour les rubyistes, il y'en a qui ont testé Sinatra et Padrino?
[...]
Des avis? Je m'y prend mal?

Essayé Sinatra (avec Haml, Sass & cie) et c'est très bien pour un petit projet sans énormément de besoins (routes, templates, tests). Va directement à l'essentiel => rapide.
Je connaissais pas Padrino, mais pas d'accord avec ta définition : je vois plus ça comme un Rails allégé dans le sens "configuration" (et éventuellement niveau perf) que "fonctionnalités" où il à l'air équivalent à Rails.

[Tomaka17]

Haha petit fail de ma part.
Sur le site que je gère j'ai un fichier log qui stocke tous les warning/erreurs PHP.

Je viens de découvrir à l'instant qu'il fait 97 Mo et qu'il est rempli de "PHP Warning: strtotime(): It is not safe to rely on the system's timezone settings."
Warning dont j'ai rien à foutre vu que je veux juste parser une date (même pas une heure) que m'envoie l'utilisateur.

[tenshu]

Ça n'empêche que configurer la timezone ça ne mange pas de pain.
Configurer un log rotation c'est bien aussi.

[Tomaka17]

Configurer un log rotation c'est bien aussi.

En fait c'est un log qui contient seulement les erreurs et warning PHP.
En théorie il doit donc être en permanence vide, c'est un peu une "liste des choses à corriger dans le code". Du coup pas besoin de "log rotation".

---------- Post added at 10h42 ---------- Previous post was at 10h33 ----------

Tiens tant que j'y pense, vous connaitriez pas une alternative à phppgadmin ?
J'ai essayé vite fait un logiciel windows nommé PGAdmin, mais il n'est pas beaucoup mieux.

phppgadmin a énormément de défauts, ou plutôt de features qui manquent :
- possibilité de modifier plusieurs colonnes ou plusieurs entrées d'un coup
- possibilité de faire une recherche rapide (par exemple si je veux voir l'élément avec l'id 123 je suis obligé d'écrire une requête SELECT manuellement)
- possibilité de cliquer sur un élément d'une colonne avec une foreign key pour accéder directement à l'élément pointé
- quand on insère un élément, les valeurs qu'on entre sont par défaut des expressions plutôt que des valeurs
- les textes sont très petits alors que le tout ne remplit que la moitié de l'écran

En fait j'envisage presque de relaisser tomber pgsql pour revenir à mysql pour mes éventuelles futures créations, juste parce que phpmyadmin est tellement mieux foutu

[tenshu]

En fait c'est un log qui contient seulement les erreurs et warning PHP.
En théorie il doit donc être en permanence vide, c'est un peu une "liste des choses à corriger dans le code".

Dans la théorie il n'y a pas de différence entre la théorie et la pratique.

Du coup pas besoin de "log rotation".

Mais en pratique il y a une différence.


Un truc comme ça peut te blinder un disque de serveur de prod à une vitesse folle.
Parfois juste par ce que les terminaux iMachin cherchent un favicon proprio à la con.
Donc je pense que ton point vu a besoin d'une légère remise en cause.

[Tomaka17]

Si c'était un site qui faisait un million de visites par jour je gèrerais les choses différemment, effectivement.

Là ça fait environ 6 mois que le site est en place, et ce log ne fait "que" 97 Mo (cela dit l'erreur n'est pas vraiment sur la page avec le plus de visites), niveau blindage de disque j'en aurais encore eu pour quelques années avant d'avoir des problèmes de capacité.

[GrandFather]

J'ai essayé vite fait un logiciel windows nommé PGAdmin, mais il n'est pas beaucoup mieux.

Pour l'utiliser quotidiennement, et écrire règles, procédures stockées et vues avec, je te trouve vachement difficile. Pour retrouver un enregistrement rapidement par exemple, il suffit de cliquer sur Filtre et de saisir simplement 'id=123' (en fait uniquement la clause WHERE d'une requête SELECT implicite). Plus simple je vois pas...

En fait j'envisage presque de relaisser tomber pgsql pour revenir à mysql pour mes éventuelles futures créations, juste parce que phpmyadmin est tellement mieux foutu

Ca, ça revient à abandonner Mercedes pour Lada parce qu'on n'aime pas la mise en page du manuel technique de la voiture. Je suis pas bien sûr que ça soit vraiment raisonnable...

[moimadmax]

Ca, ça revient à abandonner Mercedes pour Lada parce qu'on n'aime pas la mise en page du manuel technique de la voiture. Je suis pas bien sûr que ça soit vraiment raisonnable...

C'est quoi concrètement l'avantage de PGsql face à MySQL. Car dans tout les hébergements lorsqu'il y a une BDD c'est du MySQL, dès fois il y a en plus du pgSQL, mais j'ai rarement vu du pgsql seul.
Après je suis conscient que c'est par parce que tout le monde fait ainsi que c'est forcément meilleur.

[Tomaka17]

Pour l'utiliser quotidiennement, et écrire règles, procédures stockées et vues avec, je te trouve vachement difficile. Pour retrouver un enregistrement rapidement par exemple, il suffit de cliquer sur Filtre et de saisir simplement 'id=123' (en fait uniquement la clause WHERE d'une requête SELECT implicite). Plus simple je vois pas...

J'avoue que je l'ai pas testé intensivement, j'avais pas trouvé ce bouton par exemple.

---------- Post added at 11h58 ---------- Previous post was at 11h57 ----------

C'est quoi concrètement l'avantage de PGsql face à MySQL. Car dans tout les hébergements lorsqu'il y a une BDD c'est du MySQL, dès fois il y a en plus du pgSQL, mais j'ai rarement vu du pgsql seul.
Après je suis conscient que c'est par parce que tout le monde fait ainsi que c'est forcément meilleur.

Une vue qui mettait 40 secondes pour me sortir un résultat dans MySQL met moins d'une semaine dans PgSQL, c'est pour ça que j'ai switché.
Corrigez moi si je me trompe, mais PgSQL c'est un peu MySQL 7 ou 8, c'est à dire rien de fondamentalement différent mais avec des features en plus, moins de restrictions lourdingues, et tout est mieux géré.

[GrandFather]

C'est quoi concrètement l'avantage de PGsql face à MySQL.

Tout simplement l'étendue des fonctionnalités. Postgres a été conçu avec Oracle pour modèle, donc avec toutes les fonctionnalités d'un SGBDR moderne (langage procédural, procédures stockées, triggers, vues, contraintes et règles, etc.), tout un ensemble de choses que MySQL n'offre que partiellement et depuis très récemment.

Concrètement, ça permet d'implémenter un maximum de règles métiers et de traitements SQL côté BDD, et donc d'alléger en conséquence l'écriture des clients et aussi d'améliorer les performances et la robustesse.

Ainsi - et pour rester dans le sujet du topic - j'ai très peu de SQL dans mes applications Web PHP. Et le peu que j'ai n'apparaît même plus sous forme de SQL littéral, en utilisant Zend_Db_Select et Zend_Db_Table.

[olih]

J'avoue que je l'ai pas testé intensivement, j'avais pas trouvé ce bouton par exemple.

---------- Post added at 11h58 ---------- Previous post was at 11h57 ----------



Une vue qui mettait 40 secondes pour me sortir un résultat dans MySQL met moins d'une semaine dans PgSQL, c'est pour ça que j'ai switché.
Corrigez moi si je me trompe, mais PgSQL c'est un peu MySQL 7 ou 8, c'est à dire rien de fondamentalement différent mais avec des features en plus, moins de restrictions lourdingues, et tout est mieux géré.

Oui c'est sur, ça fait une différence .

[Tomaka17]

Une seconde :se-tape-la-tête-contre-le-mur:

[tenshu]

Si c'était un site qui faisait un million de visites par jour je gèrerais les choses différemment, effectivement.

Là ça fait environ 6 mois que le site est en place, et ce log ne fait "que" 97 Mo (cela dit l'erreur n'est pas vraiment sur la page avec le plus de visites), niveau blindage de disque j'en aurais encore eu pour quelques années avant d'avoir des problèmes de capacité.

Tsé c’est "juste" une question de bonnes pratiques.
Après si tu veux jouer la mauvaise foi jusqu'au bout, on peut s'interroger sur l'utilisation de pgsql sur un "petit" site.

[Tomaka17]

Je crois que le fait de passer de 40 secondes à 1 seconde pour rafraichir le cache de certaines pages est une raison suffisante.
J'essaye d'être pragmatique dans mes choix, quand j'ai besoin d'un truc je l'utilise, quand j'en ai pas besoin je l'utilise pas.

[tenshu]

D’expérience 95% du temps si une requête (même sous MySQL) met 40 seconde à s'executer.
C'est qu'il y a un problème de conception qui a été fait en amont.

[Tomaka17]

En fait j'ai environ 300 lignes de SQL où je créé des vues qui utilisent d'autres vues qui utilisent d'autres vues qui utilisent d'autres vues (j'ai entre 20 et 30 vues en tout), le tout avec énormément de jointures et de group by malheureusement obligatoires.
Niveau données brutes je vois mal comment je peux faire plus propre, et j'ai tous les index là où il faut, j'en ai même qui ne servent probablement pas.

La seule optimisation que je vois serait de créer des triggers à chaque fois que les données brutes sont modifiées, pour pouvoir mettre à jour une table intermédiaire plus facile à traiter, mais ça rendrait les calculs beaucoup plus difficiles à modifier et ça voudrait dire duplication de données.
Du coup je préfère ma solution à base de vues et de mise en cache, qui me permet en plus de vérifier les résultats intermédiaires.


EDIT : d'ailleurs dans mes souvenirs je crois que j'étais parvenu à isoler la requête qui mettait énormément de temps, du genre passage de 50 millisecondes à 20 secondes de calcul à cet endroit.
La requête en soi était vraiment simple, un group by sur une colonne d'une vue qui contenait moins de 1000 éléments, du coup j'étais parvenu à la conclusion que c'était simplement mysql qui était mal foutu.

[tenshu]

l'usine à gaz.

[Anon26492]

C'est quoi comme site ?

[Tomaka17]

Ce système de vues en question fait partie d'une application interne où tu rentres tes plannings et où ça te calcule ton temps de récup auquel tu as droit (ainsi que tes jours de congés et de RTT restants tant qu'à faire).
Faut voir que leur convention collective fait une dizaine de pages écrit en taille 12 et qu'il m'a fallu une petite semaine où j'ai tourné et retourné l'algo dans tous les sens pour le rendre le plus simple possible.

Donc par exemple j'ai une vue qui te calcule leurs heures de travail de nuit, une vue qui te calcule la liste des jours de repos (qui sont différents selon la personne), une vue qui contient la liste des semaines à prendre en compte dans le calcul global, une vue qui te comptabilise le nombre d'heures de travail majorées à 25%, une autre pour le nombre d'heures majorées à 50%, etc. enfin c'est le bordel.

[moimadmax]

Comme je ne savais pas ce que c'est qu'une vue, et que vous avez titillé ma curiosité j'ai cherché sur le Net.
Du coup j'ai remarqué des trucs qui pourrait peut être expliquer ton problème.

Les vues sont des outils très pratiques, mais leur utilisation peut causer certains problèmes de performances. En effet, on ne peut pas créer d'index sur une VIEW.

Du coup il faut faire des tables matérialisées, en gros des tables à la places des views mise à jour par des triggers.
En même temps quand on voit la masse de trigger pour le petit exemple ça fait peur. Et ca peut vite amener une jolie boucle infini de triggers.

En même temps si tu es content avec PGsql, ça sert a rien de se prendre la tête avec cela. Si tu peux changer le serveur SQL c'est pas mal. Moi j'ai déjà du coder un semblant de base de données à base de fichiers, car le mec voulait bien activer le module PHP, mais pas installer MySQL, et non SQLite n'existait pas encore.
Puis bon je suis pas un dieu de la prog non plus.

source

[deathdigger]

J'avais lu une info je ne sais où qui précisait que PgSQL pouvait supporter des bases de 13To sans broncher. Pas sûr que ça marche avec mySQL