La lettre et l'esprit de la charte veulent que vous ayez une attitude responsable quant aux scripts que vous utilisez, c'est à dire que vous devez veiller à ce qu'ils ne consomment pas trop de ressources sur le serveur, afin qu'ils ne genent pas l'ensemble des utilisateurs.

Si vous ne comprenez pas trop ce qui est attendu, voici quelques conseils utiles :

Vous voulez installer un script

Il est peut-être inutile

L'APINC fournit de nombreux services aux membres, il faut les utiliser plutôt que d'installer des scripts faisant la même chose.
C'est le cas pour :

• les statistiques: des statistiques sont générées pour chaque espace web, celles-ci sont très précises. Vous n'avez donc pas à installer un script pour générer vos statistiques. Pour accéder aux statistiques de votre site web, allez sur http://stats.apinc.org ( exemple de statistiques)
• les compteurs: un outil complet de gestion de compteurs de pages web est à votre disposition : Compteurs APINC
• les listes de diffusion: un système très complet de listes est offert aux membres, il est plus que recommandé de l'utiliser à la place d'un quelconque script de gestion d'une liste de diffusion. Plus d'information.

Il est peut-être interdit

La charte interdit explicitement et implicitement certains types de scripts, en voici une liste non exhaustive (si vous ne savez pas comment vérifier certains points, n'hésitez pas à demander conseil) :

• les scripts de chat, ainsi que les CGI::IRC. Vous pouvez à la place créer un canal irc et mettre en place une applet java pour y accéder (comme par exemple pjirc
• la commande pconnect dans un script le rend incompatible avec les serveurs de l'Apinc
• l'utilisation de requêtes DELAYED n'est pas possible (exemple SPIP ancienne version 1.4, veuillez utiliser une version patchée ou plus récente)

Il est peut être déconseillé

Tous les scripts que vous installez devraient être dans une version STABLE. Il est dangereux de mettre des scripts non éprouvés sur un serveur mutualisé.
Il est recommandé dans la charte de n'utiliser que des scripts conseillés par des admins.
Si parmi les scripts conseillés aucun ne correspond à vos besoins, vous pouvez demander conseil sur le forum apinc.aide ou sur irc

Il est peut-être excessif

En règle générale, il ne faut mettre sur votre site que des choses que vous utilisez réellement, mettre trop de choses risque de le faire passer pour un jouet plus que pour un site sérieux par vos visiteurs. Par exemple, mettre en place un système de sondage est rarement utile, parce que les sujets de sondage s'épuisent vite, et vous finissez soit par laisser une question pendant des mois, soit par faire des sondages ridicules qui font perdre de la crédibilité à votre site.
Si votre projet a été accepté par les membre de l'APINC, c'est sûrement parce que vous avez à partager un contenu intéressant. Alors rappellez-vous que l'essentiel est dans le contenu, pas dans les gadgets.
Donc, si vous trouvez un script qui propose entre autres une solution à ce que vous cherchez, mais qui fournit par ailleurs des tonnes de fonctionnalités que vous ne recherchiez pas, sachez qu'il n'est pas recommandé du tout de l'utiliser.

Vous voulez créer un script

Les conseils donnés ci-dessus restent applicables pour les scripts que vous créez.

Il n'y a pas de serveur de développement

Cela est très important. Tous les scripts mis sur les serveurs de l'apinc doivent avoir été préalablement testés avec succès par vos propres moyens?.
L'apinc ne propose aucune machine pour faire du développement, donc si vous mettez un script non testé en ligne vous le faîtes sur un serveur en exploitation, c'est-à-dire que vous mettez égoïstement en danger des centaines de sites de membres innocents.
Ce comportement est générallement reconnu comme intolérable dans une association.

Ne réinventez pas le fil à couper l'eau chaude

• Utilisez les scripts recommandés : si un script conseillé correspond à ce que vous souhaitez réaliser, il est recommandé de l'utiliser plutôt que de vous lancer dans la programmation d'un nouvel outil. Les scripts conseillés sont tous libres, donc s'il faut l'adapter à vos besoins vous pouvez le faire, vous pouvez même soumettre votre modification à l'auteur du script et ainsi rendre service à des centaines de gens.
• Apprenez le langage que vous utilisez, par exemple si vous devez travailler sur des tableaux, apprenez toutes les fonctions qui existent sur les tableaux avant de vous lancer dans la programmation. Vous verrez par exemple qu'il existe des fonctions de tri de tableau, et sachez qu'elles sont bien meilleures que toutes celles que vous pourriez écrire (à moins que vous soyez un pro de l'algorithmique et que vous puissiez optimiser pour votre script le nombre d'éléments pour lequel le tri récursif a une complexité inférieure au tri par tas - si vous ne comprenez pas ce qui est dans cette parenthèse, n'écrivez jamais une fonction de tri). De même, si vous faites des scripts CGI en python ou perl, pensez à utiliser les bibliothèques qui sont à votre disposition plutôt que d'écrire vous-même certains éléments plus ou moins complexes, vous gagnerez du temps et vous serez sûr d'utiliser quelque chose de testé et optimisé.

On ne fait pas tout avec HTTP

Si vous créez vos scripts vous-même, vous devez avoir totalement conscience de ce que vous utilisez, alors n'oubliez jamais que lorsque vous faîtes des scripts PHP ou CGI vous travaillez sur le protocole HTTP, qui a plusieurs particularités qui le rendent inadapté à certains types de programme:

• une information = une connexion, c'est-à-dire qu'à chaque fois que le navigateur demande une donnée, une connexion est créée, toutes les informations concernant la connexion sont passées (du côté du client comme du côté su serveur). HTTP n'est donc pas adapté pour faire un programme qui nécessite plusieurs communications entre l'utilisateur et le serveur, tout ce qui nécessite un rechargement régulier de la page est générallement mauvais (exemple: système de messagerie instantanée, chat, jeu vidéo en temps réel)
• l'information passe en clair, c'est à dire que vous ne pouvez pas crypter les informations que vous faîtes passer par http. Les systèmes permettant de crypter les données lors du transfert avec un décryptage javascript par le navigateur sont d'une part inefficaces, parce que le système de décryptage est transféré en clair, et d'autre part très consommateurs en ressources, parce que l'algorithme de cryptage utilisé est générallement l'oeuvre d'un amateur. Il est donc recommandé de ne pas utiliser un tel système.

Finalement, vous programmez

Sur un serveur mutualisé, il faut consommer le moins de ressources possible, c'est-à-dire créer un code qui demande le moins de travail possible à la machine que vous partagez avec des centaines d'autres sites. Voici quelques petites idées qui pourront vous permettre d'avoir un programme plus léger (et surtout plus rapide, vos visiteurs apprécieront).

Savoir stocker

N'utilisez des bases de données qu'en cas de réel besoin de faire des requètes complexes nécessitant l'utilisation d'un langage tel que SQL.

• contrairement à ce qu'affirme une rumeur assez répandue, les systèmes de gestion de bases de données (SGBD) n'ont jamais été créés pour faire du stockage d'information. Si celui qui est utilisé sur les serveurs de l'APINC s'appelle MySQL, et non pas myStock c'est bien parce que ce qui est intéressant dans un SGBD est le langage de SQL et non-pas le stockage des informations
• ayez toujours à l'esprit que lorsque vous faites une requète SQL, vous lancez un processus complexe (analyse syntaxique, analyse lexicale, optimisation, interprétation, appel de routines, ouverture de fichiers, etc.). La rumeur selon laquelle utiliser un fichier est moins performant qu'utiliser une base de données est fausse et risible, si cela était vrai MySQL n'utiliserait pas de fichiers pour stocker ses propres données!
• des modules ont été développés pour permettre une manipulation simple de fichiers. Ils ne sont pas tous aussi performants, n'hésitez pas à les comparer ou à vous faire conseiller

Connaître SQL

Si finalement vous avez besoin d'utiliser un système de gestion de bases de données, c'est sûrement parce que vous avez des relations complexes entres des tables à gérer. Cependant les docs SQL que vous avez pu lire peuvent être périmées, ou ne pas correspondre exactement à ce que propose MySQL qui est le seul SGBD disponible sur les serveurs de l'APINC. Voici quelques règles de base auxquelles vous devez penser :

• si vous devez faire un SELECT, la clause FROM ne doit contenir directement qu'une seule table, quelque chose du type "FROM table1, table2, table3" crée un immense tableau en mémoire, contenant le produit de toutes les combinaisons possibles entre ces 3 tables (si elles ont chacune 100 lignes et 5 colonnes, on a en mémoire un tableau de 1000000 de lignes et 25 colonnes, immaginez ce que ça donne avec encore plus de tables ou plus de lignes par table). Les normes plus récentes de SQL définissent les clauses JOIN permettant d'éviter ce problème, en ne chargeant en mémoire que les informations utiles. Cela rendra votre code bien plus lisible et votre script bien plus rapide, vous avez tout à y gagner ;
• pensez également à créer des index pour accélérer les traitements. Les index doivent être mis sur les colonnes qui sont souvent appellées dans des clauses select. De nombreuses documentations existent à ce sujet, n'hésitez pas à passer du temps à les consulter, n'oubliez pas que ce sont vos viisiteurs qui en profiteront les premiers, ainsi que l'ensemble des autres sites de l'Apinc indirectement ;
• lorsque vous faîtes un INSERT ou un UPDATE, vous ne devriez pas avoir besoin de faire un SELECT avant. Si vous le faîtes, c'est sûrement parce que vous ne connaissez pas les possibilités de MySQL, qui permet de générer automatiquement des identifiants, de gérer les doublons, de mettre à jour les tables selon des critères avancés, avec tout type de données. Lisez la documentation de MySQL (elle existe en Français);
• pensez également à bien choisir vos types de colonnes, ce choix peut optimiser très largement le fonctionnement de votre script, mais aussi l'espace occuppé sur le disque, en faisant attention aux possibilités de modificateurs UNSIGNED qui permettent de doubler vos possiblités dans certains cas. Après avoir lu la documentation de MySQL, cela n'aura plus de secret pour vous!

Attention aux expressions régulières

Les expressions régulières permettent de définir des langages, c'est à dire que c'est un mécanisme très puissant qui nécessite l'utilisation d'un moteur d'optimisation et d'interprétation assez complexe.

• vous devez donc éviter au maximum de les utiliser (même en perl). Si vous n'avez pas besoin de définir un langage (typiquement: vous savez exactement le contenu de la chaîne que vous recherchez), vous devez utiliser les fonctions de traitement de texte offertes par votre langage de programmation préféré, les documentations sont très fournies à ce sujet
• si vous devez réellement utiliser des expressions régulières, pensez à demander conseil pour les optimiser au maximum. En PHP, préférez les preg aux ereg. En perl, lisez la documentation avancée à ce sujet. Pour les autres langages, renseignez-vous sur la librairie la mieux adaptée à vos besoins.

Éviter les appels de programmes

Les langages offrent généralement le nécessaire pour faire ce dont vous avez besoin (notamment python et perl via de nombreuses bibliothèques), évitez donc au maximum de faire des appels aux applications du serveur. Cela rendra votre application plus rapide, plus sûre et surtout plus pérenne, parce qu'il n'est aucunement garanti que les applications actuellement accessibles par les scripts CGI le seront demain.

---