Reflectiv - The digital agency

Voici une petite image qui vaut bien plus que de longues explications sur les tailles prises en comptes par les principaux moteurs de recherche pour les balises html title, description et url :

De manière générale, je vous conseille les articles de Seomoz.org pour leurs conseils sur l'optimisation de vos sites.

Lors de la FOWA conférence qui s'est déroulée à Miami, Fred Wilson à présenté ce qui correspondait selon lui aux 10 principes essentiels à la réussite d'une application web.

Carsonified à publié la conférence de Fred Wilson sur Vimeo, et les conseils donnés par ce dernier sont très intéressants !

Pour information, voici les 10 conseils :

1. Speed
2. Instant utility
3. Voice
4. Less is more
5. Programmable
6. Personal
7. Restful (pas dans le sens software architecture)
8. Discoverable
9. Clean
10. Playful

Vous pouvez voir la vidéo ci-dessous ou lire directement le transcript.

L'article de blog dont fait référence Fred Wilson se trouve ici et je vous conseille aussi fortement de lire les commentaires (malgré le nombre rebutant), qui apportent eux aussi leur brin d'idée sur les autres points utiles à la réussite d'une application web.

Il existe de nombreuses pratiques pour développer du code propre, pérenne et accessible. Nommer la liste ici serait une perte de temps.

Parmi toutes ces lois, techniques et conseilles, la liste des 13 plus mauvaises pratiques appliquées à Rails soulève un point intéressant que l'on ne retrouve pas forcément dans les sites à base de Frameworks :

Chubby Controllers Must Die

There should be no business logic in a controller.

Read that again.

There should be no business logic in a controller.

Controllers do two things: they take data from the params or session and send it to the model. The MODEL performs all the necessary logic. Then, the controller does the other thing that's completely necessary: it decides what should be shown to the user. That's it. The sum total of a controller action is two steps long.

1. Send information to the model.
2. Decide what to display.

If you are doing ANYTHING ELSE in your action, you are doing it in the wrong place. The end.

Le problème n'est pas forcément le développeur, qui ignore cette pratique, mais aussi les créateurs du framework, qui, par l'absence de composants adaptés, force le développeur à mettre du code métier dans ses controlleurs.

J'apprécie particulièrement cette remarque qui soulève un point fondamental sur l'usage des frameworks et prouve que leur utilisation n'est pas le stade ultime en matière de développement efficace.

Ce n'est pas parce que vous utilisez un framework que vous faites les choses bien !

Nous considérons que le temps est venu de nous séparer de Black-Frames car ce dernier ne corresponds pas à nos objectifs en terme de projets.

Ainsi nous proposons l'acquisition du nom de domaine, des images, des sources et des différents scripts au plus offrant.

Voici ce que représente Black-Frames :

• Un site développé en Django (Python) avec une base de donnée MySQL
• Actuellement plus de 1100 images (et le nombre ne cesse d'augmenter)
• Un minimum de 100 visiteurs unique par jours
• Déjà plus de 18.000 visites depuis sa sortie le 20 août 2009
• Plus de 195.000 pages vues
• Une moyenne de 130 visiteurs par jours
• Une moyenne de 10.60 pages vues par visites
• Un temps moyen passé sur le site de 4 minutes et 17 secondes
• Et 43.07% de nouvelles visites

Vous pouvez nous contacter par email ou par téléphone, pour avoir plus de détails et/ou nous faire votre offre.

La réalisation de GSPanel avance tranquillement, et je bloque actuellement sur un point, donc j'aimerai votre avis.

Lorsqu'un utilisateur aura ajouté une machine, il devra ajouter des jeux. Au niveau structurel, la page d'ajout proposera au tout début une simple liste déroulante, contenant tous les jeux proposés. Une fois que l'utilisateur aura fait son choix, le vrai formulaire apparaîtra avec les valeurs adéquates (nom du jeu, version, dossier d'installation, etc).

Le problème est au niveau des jeux. A la base, je pensais que le mieux était de faire un fichier xml par jeux. Ce fichier contiendrait les informations suivantes :

• Nom (du jeu)
• Version
• Logo
• Chemin du script d'installation (sur nos serevurs)
• Liste de paramètres pour le script
• Chemin d'exécution du jeu
• Paramètres pour lancer le jeu (tel que port, ip, etc)

(d'ailleurs, si j'en oublie, n'hésitez pas !)

Le problème, est que pour afficher une liste de 50 jeux, il faudra parcourir 50 fichiers, et en plus ouvrir celui que l'utilisateur aura sélectionné pour récupérer les autres données, et cela à chaque fois que l'utilisateur affichera la page "Ajouter".

Ça peux vite devenir lourd !

Du coup, j'aurais deux solutions, mais j'aimerai vos avis (quelle solution serait la meilleure ? (d'autres propositions sont permises)) :

1. Faire un master file xml, qui contiendrait la liste des fichiers xml avec le nom du jeu (la liste affichera le nom et aura comme clée le fichier).
   Le problème avec cette méthode est qu'il faut mettre à jour le master file à chaque fois qu'un nouveau jeu est ajouté.
2. L'autre solution consisterait à tout mettre en base. On oublie complètement le chargement des fichiers xml dans ce cas. Là, le problème est que cette implémentation impose la création de trois nouvelles tables : les informations du jeu, les paramètres du script d'installation et les paramètres du jeu.

D'après vous, quelle serait la meilleure méthode, laquelle utiliseriez-vous ? Serait-ce la 1 ? la 2 ? ou une autre carrément plus adaptée ? :)

Merci de me laisser vos avis !